On Fri, 2017-01-13 at 09:48 -0500, Stephen Smalley wrote: > On Thu, 2017-01-12 at 23:42 +0000, Alan Jenkins wrote: > > > > My main puzzle here[*] is why `fixfiles` handles sysfs (/sys/) > > fine, > > but > > then there's floods of warnings about debugfs > > (/sys/kernel/debug/). The > > same seems to happen with /dev/ being fine, but not the other > > virtual > > fs's with seclabel which are mounted in subdirectories of /dev/. > > This is a bug/regression. Thanks for reporting it. In commit > 36f1ccbb5743749c404ad8f960867923544b90d9, Dan added this warning but > only if the user explicitly does a restorecon /path/to/foo and > /path/to/foo does not have any matching label in file_contexts; in > the > case of a restorecon -R or setfiles, it isn't supposed to happen. > The > check on the recursive flag got dropped when this logic was taken > into > selinux_restorecon(3) in libselinux > (commit f2e77865e144ab2e1313aa78d99b969f8f48695e). Will fix. Actually, I am wrong about this being a regression (and I should have known that, since the buggy version is 2.5 and that precedes the latter commit). Looking at the first commit, the original logic was to display a warning if not recursive OR verbose, so it would unconditionally log a warning if you did restorecon /path/to/foo or restorecon -v /path/to/foo or restorecon -Rv /path/to/foo, just not if you did restorecon -R /path/to/foo. When it was moved to libselinux selinux_restorecon(3), it was changed to log a warning if verbose, so it logs a warning if you pass -v (with or without -R) but not if you just do restorecon /path/to/foo. The patch I sent makes it only log the warning if verbose and not recursive, so it will only log if you pass -v without -R. To be honest, I'm not sure what the point of this warning is; it is perfectly valid for an entry to have <<none>> to indicate that it should not be relabeled at all by restorecon/setfiles. Maybe we should just remove the warning altogether. _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
