On Tue, 30.04.13 00:03, Christian Hesse (m...@eworm.de) wrote:
> Hello everybody,
>
> ok, this looks very tricky... I have no idea what happens and I have no way
> to reproduce this. It just happens from time to time - very seldom.
>
> If this happens I am not able to log in from lxdm and getty. The only way back
> into the system is getting a failed login from getty, it succeeds after the
> process has been restarted. From there I can restart lxdm unit.
>
> Looks like lxdm-binary gets 'permission denied' when accessing some file.
> This is strace from lxdm-binary, grepped for 'EACCES':
>
> open("/etc/pam.d/eworm-yubico-otp", O_RDONLY) = -1 EACCES (Permission denied)
> open("/var/log/faillog", O_RDWR) = -1 EACCES (Permission denied)
> open("/var/log/faillog", O_RDONLY) = -1 EACCES (Permission denied)
> open("/dev/bus/usb/001/002", O_RDWR) = -1 EACCES (Permission denied)
> open("/etc/shadow", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
>
> lxdm-binary is running with user and group 'root' so I do not understand why
> permissions for other take effect.
>
> This is an Arch Linux system with Linux 3.8.8-1-ARCH and systemd 202-1.
> Any ideas?
My guess is that lxdm is broken and reuses the process that invokes the
PAM session hooks? That means the first login on the display would work,
but the second one wouldn't.
PAM clients need to open the PAM session in a process, then fork the
child off, wait for it to die via waitpid, then close the PAM session in
the original process, and then exit in that original process. Everything
else is broken.
Lennart
--
Lennart Poettering - Red Hat, Inc.
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
