Re: noisy selinux messages on tmpfs mount.

[Stephen Smalley]

On 01/12/2015 09:51 AM, Christopher J. PeBenito wrote:
> On 1/9/2015 3:47 PM, Stephen Smalley wrote:
>> On 01/09/2015 02:13 PM, Dave Jones wrote:
>>> On Fri, Jan 09, 2015 at 08:06:49AM -0500, Stephen Smalley wrote:
>>>  
>>>  > On Thu, Jan 8, 2015 at 2:39 PM, Paul Moore <pmoore@xxxxxxxxxx> wrote:
>>>  > > On Thursday, January 08, 2015 02:34:57 PM Paul Moore wrote:
>>>  > >> On Thursday, January 08, 2015 02:08:22 PM Dave Jones wrote:
>>>  > >> > systemd has started mounting a tmpfs in /run/user/<uid> every time a
>>>  > >> > session begins.  So after ssh'ing into a box a number of times, dmesg
>>>  > >> > looks like this..
>>>  > >> >
>>>  > >> > [...] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
>>>  > >> > [...] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
>>>  > >>
>>>  > >> {snip}
>>>  > >>
>>>  > >> > What's a good solution to stopping this spew ? printk_once doesn't seem
>>>  > >> > like a good fit, in case someone is doing different labelling behaviours
>>>  > >> > between mounts.
>>>  > >> >
>>>  > >> > Could we only print it if the mount is being done with non-default
>>>  > >> > behaviour perhaps?
>>>  > >>
>>>  > >> I'm very curious to hear Stephen's opinion on the issue, but I wonder how
>>>  > >> much this would honestly impact us if we removed this message in the case
>>>  > >> where we mount the filesystem with a known labeling behavior.
>>>  >
>>>  > We already reduced that message to KERN_DEBUG.  Is that not sufficient?
>>>
>>> That doesn't really help with the flooding of dmesg, so no.
>>> I should also note that it's not just logging in that creates a new
>>> session, it also seems to be getting triggered by cron jobs, or
>>> whatever the systemd replacement is.
>>
>> Fair enough.  I think we can likely get rid of it then.
> 
> Are you saying completely get rid of the message in all cases?  If so,
> how is a user supposed to debug situations where they mount a filesystem
> and labeling doesn't work (i.e. no security label support or policy
> hasn't been updated for that fs)?  Is there going to be another place to
> look see what the labeling behavior is for all mounted filesystems?

In most cases, they can extract the information directly from the policy
via seinfo or their favorite policy tool.  For mountpoint labeling, the
printk in question only tells them that mountpoint labeling was used,
not the specific option and value, so reading /proc/self/mounts is more
informative.  /proc/self/mounts will also tell them whether the
filesystem "supports" labeling via the seclabel option.  So I don't
believe it offers us any information that isn't available elsewhere.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/