Project

General

Profile

Actions

Bug #509

closed

at/batch broken

Added by qhwt+dfly almost 18 years ago. Updated almost 18 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

Hello.
Original issue has been posted to kernel@
http://leaf.dragonflybsd.org/mailarchive/kernel/2006-09/msg00028.html
but since the thread has turned into how you use macro or inline functions,
I'm going to raise this topic on bugs@ again :-)

The problem: at or batch command fails to accept a new schedule
because it fails to create a lock file /var/at/jobs/.lockfile.
The bug exists in 1.4/1.6 releases too. It's not the permission or
configuration file:
$ su # cat /var/at/at.allow
qhwt # ls -l /usr/bin/at
-r-sr-xr-x 4 root wheel 19316 Jan 3 21:02 /usr/bin/at # exit
$ id
uid=1000(qhwt) gid=1000(qhwt) groups=1000(qhwt), 0(wheel)
$ at 1:00 echo
at: cannot open lockfile /var/at/jobs/.lockfile: Permission denied

The root cause is, as I posted in that thread, second call to setreuid()
fails if you don't close a file descriptor you opened right after the
first call to setreuid(real_uid, effective_uid) with the same argument
fails, whether you close the descriptor or not. I'm attaching the sample
code again. It fails on DragonFly, but succeeds on FreeBSD. I looked
around in the kernel code but I couldn't find any description that it's
a security feature specific to DragonFly.

Regards.


Files

at.c (728 Bytes) at.c qhwt+dfly, 01/07/2007 08:34 AM
Actions #1

Updated by qhwt+dfly almost 18 years ago

blush here you are.

Cheers.

Actions #2

Updated by TGEN almost 18 years ago

I remember having to touch the .lockfile and .SEQ before being able to
use at(1) as well, on at least as early as 1.3.

No idea, but I also haven't looked at any code...

Cheers,
--
Thomas E. Spanjaard

Actions #3

Updated by corecode almost 18 years ago

fixed

Actions

Also available in: Atom PDF