New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no "systemd --user" started for NIS user #15705
Comments
The
Services appear to be running:
|
NSS passwd database modules that directly contact the network are so 90's. It's a massive security problem loading a network client into every process. We lock this down in systemd-userdb.service, i.e. use If you can't fix NIS to behave better and not expect networking to work from every single process on the system, then consider adding a drop-in to systemd-userdbd.service, that unsets IPAddressDeny=any so that the daemon is wide open again. Consider asking your distro packagers to just package a drop-in like that for systemd-userdbd.service as part of the NIS package, they must be shipping one just like that for systemd-logind.service already, since we block that there too. The security benefit for locking this down is major, and only really old NSS modules need direct network access, hence I am sure the benefit for the many trumps the incompatibility with NIS on this. Hence I don't think we should change anything in systemd here. Sorry if that means extra work and trouble! |
Thanks, this helped greatly. For reference to anyone googling this - after unsetting However, as per previous recommendations, starting Fedora bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1831141 |
systemd version the issue has been seen with
systemd 245 (v245.4-1.fc32)
Used distribution
Fedora 32
Expected behaviour you didn't see
ypwhich
from localhost) login is slow (45sec delay)systemd --user
is NOT startedXDG_
variables are not setsystemd-userdbd
reportsyp_bind_client_create_v3: RPC: Unable to send
pamd_systemd
reportsFailed to get user record: Connection timed out
journalctl
Starting
nscd
does not solve problem.Local user (not in NIS) does not have same problem.
Unexpected behaviour you saw
systemd --user
not started for NIS userSteps to reproduce the problem
authselect select nis --force
authselect enable-feature with-pamaccess
/etc/nsswitch.conf
The text was updated successfully, but these errors were encountered: