On 9/29/2016 5:55 PM, Kevin Kofler wrote:
Nobody should ever add this at all. And most definitely not Fedora. The behavior the original poster pointed out: | - su -s /bin/bash - nologinuser (if "nologinuser" has /sbin/nologin as the | default shell) succeeds with /bin/bash if auth is successful [2], even | though man 1 su, man 8 nologin, and man 5 shells suggest that such a user | is a restricted user and logging in with an alternate specified shell | should be forbidden. sounds very much like a critical privilege escalation security hole to me, that should get a CVE and be fixed in all supported Fedora releases ASAP!
How is this a "critical...security hole"? I seriously can't be the only person out there that intentionally sets accounts to /sbin/nologin if they don't need to log in (as another layer of security), but occasionally runs 'su -s /bin/my/shell/of/choice uid' when I need to do some work under it, can I?
In any event, this has been this way for 14 years. There are legitimate reasons for wanting a "valid" shell that, nevertheless, results in disallowing remote logins in a human-readable way. The traditional solution IIRC had been to set someone's shell to /bin/false, but I fail to see why -- 14 years later -- this is something I need to get a warning about, let alone something to be considered an actual problem. A sysadmin who runs "usermod -s /sbin/nologin" knows what they're doing.
If, as mentioned at https://bugzilla.redhat.com/show_bug.cgi?id=53963#c7, it didn't cause a problem in the first two years, "fixing" it 12 years after that seems unnecessary. We "fix" enough perfectly-working stuff in Fedora as it is...
+1 to fixing this by updating the shells man page as indicated in https://bugzilla.redhat.com/show_bug.cgi?id=1218302#c4
Regards, -jc _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
