1) When sys-process/at-3.1.10.2-r1 is compiled with USE=-pam ALL JOBS ARE RUN AS ROOT instead of the caller! To reproduce: # echo 'touch /tmp/test' | sudo -u games at now # ls -l /tmp/test 2) If at is compiled with USE=pam then users that are listed only in /etc/passwd don't work. Ldap-users do work. Explanation of reasons in https://bugzilla.redhat.com/show_bug.cgi?id=150131 Work around is to put following line to /etc/pam.d/atd account required pam_permit.so Before upgrade version 3.1.8-r11 did work without problems so I suggest removing 3.1.10.2-r1 from portage immediately. Environment: gcc version Gentoo 4.3.2-r3 p1.6 arch x86
For what PAM is concerned, so point (2), I don't think that pam_permit line is going to help us at all, if anything it's going to be worse. Please note that the Red Hat bug you point to shows a completely different PAM setup than ours. Unfortunately we have currently no officially-supported LDAP setup for Gentoo Linux so I'd have to ask you to post your system-auth configuration; that's probably a different bug though so please report it separately.
(In reply to comment #0) > 1) When sys-process/at-3.1.10.2-r1 is compiled with USE=-pam ALL JOBS ARE RUN > AS ROOT instead of the caller! > > To reproduce: > # echo 'touch /tmp/test' | sudo -u games at now > # ls -l /tmp/test I cannot reproduce this: alex@neon ~ $ echo "whoami > /tmp/atuser" | sudo -u rbot at now warning: commands will be executed using /bin/sh job 6 at Sun Apr 26 10:31:00 2009 alex@neon ~ $ cat /tmp/atuser rbot (The games user is by default not even allowed to create at jobs...) > 2) If at is compiled with USE=pam then users that are listed only in > /etc/passwd don't work. Ldap-users do work. Explanation of reasons in > https://bugzilla.redhat.com/show_bug.cgi?id=150131 > Again, using the rbot user (no LDAP on my system), it "works". Assigning to correct component, resetting priority and severity until we can confirm this.
*** Bug 267498 has been marked as a duplicate of this bug. ***
After trying to reproduce issue 1) again on another installation which did not work, I'll close this bug. If you can produce further evidence that this is a reproducible issue, please reopen this bug.
