From: Stephen Smalley <sds@tycho.nsa.gov>
To: Alan Jenkins <alan.christopher.jenkins@gmail.com>, selinux@tycho.nsa.gov
Subject: Re: [PATCH] restorecon manpage: link back to fixfiles
Date: Fri, 13 Jan 2017 10:27:59 -0500 [thread overview]
Message-ID: <1484321279.32375.44.camel@tycho.nsa.gov> (raw)
In-Reply-To: <1484318901.32375.32.camel@tycho.nsa.gov>
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.
next prev parent reply other threads:[~2017-01-13 15:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-11 12:41 [PATCH] policycoreutils, python: Fix bad manpage formatting in "SEE ALSO" Alan Jenkins
2017-01-11 12:41 ` [PATCH] restorecon manpage: link back to fixfiles Alan Jenkins
2017-01-12 20:01 ` Stephen Smalley
2017-01-12 20:47 ` Alan Jenkins
2017-01-12 21:23 ` Stephen Smalley
2017-01-12 23:42 ` Alan Jenkins
2017-01-13 14:48 ` Stephen Smalley
2017-01-13 15:27 ` Stephen Smalley [this message]
2017-01-13 18:29 ` Daniel J Walsh
2017-01-13 19:38 ` Stephen Smalley
2017-01-13 19:56 ` Alan Jenkins
2017-01-13 20:13 ` Alan Jenkins
2017-01-13 15:37 ` Stephen Smalley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1484321279.32375.44.camel@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=alan.christopher.jenkins@gmail.com \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.