Re: file_context.local and relative paths
On 03/19/2014 12:29 PM, Shade, Matt (US) wrote:
Hi folks,
This is more of a curiosity question, and I haven’t found any answer yet.
If I receive an AVC and sealert tells me to
chcon –R –t something_log_t ‘./logs’ with a subsequent semanage
then it goes into file_context.local exactly how I entered it.
Cool, I would expect that. But it got me thinking about
setfiles/restorecon, and what if I have another directory named logs
that requires relabelling?
For example, let’s say that today I find incorrect labelling on
/somedir/logs and so I fix it with chcon/semanage.
Then next year, I add a new application and it has /anotherdir/logs that
is incorrectly labelled. SELinux is going to complain about ./logs
again, so I may just cd into /anotherdir and do my chcon/semanage with
another_log_t label to this ./logs.
That would change the old label, I would think (unless I’m relabelling
to the same label), and so now restorecon ./logs will apply the new
label to whichever directory I would have to fix.
Also, say I actually think about that beforehand and decide to use a
full path in my restorecon command -- restorecon –v /somedir/logs --
will it be smart enough to know which logs entry in file_context.local I
mean, or do I have to remember that I used a relative path when I
created the entry and use that in the restorecon command?
So I guess ultimately the question is, wouldn’t it be better for
semanage to require full paths?
IMHO, that's a bug and should get a bugzilla on policycoreutils or
libsemanage - paths in file_contexts* should always be absolute.