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.
