Hello Evgeny, this bug has been open for almost 7 years. I ran some tests, and I think the underlying issue has been solved, one way or another (see below).
Evgeny Stambulchik wrote: > Steve Greenland wrote: >> On 10-Aug-03, 06:32 (CDT), Evgeny Stambulchik >> <fnevg...@plasma-gate.weizmann.ac.il> wrote: >>> A job assigned to a userid which isn't in /etc/shadow (though exists in >>> /etc/passwd) isn't executed and no error is syslog'ed. If it matters: I >>> use a mixed files/ldap nss config; the user doesn't exist in the LDAP >>> DB either. >> >> And why do you think it should work? The shadow database is an intrinsic >> part for (local) user identity. > > It's an authentication part, it has nothing to do with identity. I want > to run a job under an unprivileged account, and all I need is a mapping > between a username and an uid; /etc/passwd is completely adequate for > this purpose. Notice I mean a cron job specified via a /etc/cron.d/ > script, not by crontab -u (the latter may probably need /etc/shadow to > verify if an account is expired). In fact, cron jobs in /etc/cron.d also check in /etc/shadow for password expiry, etc. Looking at PAM's source code, this error appears to be fatal (as in your case) only if the password field in /etc/passwd contains an "x", in which case an entry MUST exist in /etc/shadow. This is described in passwd(5). I tested this with a sample entry in /etc/password: I) testuser:x:10100:10100::/:/bin/bash II) testuser:!:10100:10100::/:/bin/bash The first entry produces the error you describe - the specified cron job does not get executed. The second one, however, runs fine. > I don't see why the result should be > different from su - <username> -c [...] which works fine without the > respective /etc/shadow entry. I can't explain this one, either. Did you perhaps run su - c [...] as root? >> If there's actually some documented reason that it should, though, then >> it's either a libc or PAM problem. > > Maybe. I can't tell for sure, but it seems it worked ok before upgrading > to testing from stable. > >> Do you get an error in auth.log from PAM? > > As I said, no. The current PAM version in sid (1.1.1-2) logs an Authentication error to syslog. Please let me know if you still have this issue or if I can close this bug. Christian
signature.asc
Description: OpenPGP digital signature
