file_context.local and relative paths

[Stephen Smalley]

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.