On Thu, 22 Mar 2018 13:04:28 -0400 Stephen Smalley <sds@xxxxxxxxxxxxx> wrote: > On 03/22/2018 07:55 AM, Paul Howarth wrote: > > I've seen a few reports that proftpd's sftp support isn't working > > with SELinux in enforcing mode: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1529576 > > https://github.com/proftpd/proftpd/issues/659 > > > > Using strace, it appears that proftpd is rejecting logins after > > failing to access /etc/shadow, but why would it be doing that at > > all, rather than using the unix_chkpwd helper? > > > > Googling this, the only similar issue I saw was this: > > http://blog.siphos.be/2014/12/why-does-it-access-etcshadow/ > > but this seems to be different because ftpd policy does include > > auth_use_pam. > > > > Any thoughts on this? I did try this locally and couldn't reproduce > > it, so it seems to be configuration/environment-specific rather than > > something being fundamentally wrong. > > Is it possible that proftpd is running in a chroot environment with a > read-only or non-exisitent selinuxfs mount, faking libselinux into > believing that SELinux is disabled (and thus pam doesn't bother > trying to run unix_chkpwd when it runs with uid 0)? Not sure about the vagrant example in github, but the example from bz.redhat.com is a regular install, and the reporter says he says the same behaviour on both machines he's tried. The strace logs from bz.redhat.com don't contain the string "selinux"; shouldn't there be an access to something under /sys/fs/selinux to check if SELinux is enabled? Paul. _______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
