noisy selinux messages on tmpfs mount.

noisy selinux messages on tmpfs mount.

[Dave Jones]

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..

[  929.892760] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[ 4529.025836] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[ 8129.170484] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[11729.313034] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[15329.471269] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[18929.613781] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[22529.759596] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[26129.890709] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[26669.001664] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[33328.937304] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[36929.064927] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[40529.178574] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[44129.301952] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[47729.424882] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[51329.287032] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[54929.563390] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[58529.857740] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
[62128.992792] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs

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?

	Dave

Re: noisy selinux messages on tmpfs mount.

[Paul Moore]

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.

-- 
paul moore
security @ redhat

Re: noisy selinux messages on tmpfs mount.

[Dave Jones]

On Thu, Jan 08, 2015 at 02:34:57PM -0500, 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.
 
It would help if I had cc'd Stephen's correct email address.
Stephen, for context: https://lkml.org/lkml/2015/1/8/468

I figured there would be pushback from removing it entirely, which is
why I didn't send the obvious patch.

	Dave

Re: noisy selinux messages on tmpfs mount.

[Paul Moore]

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.

[NOTE: adding the SELinux list to the CC line.]

-- 
paul moore
security @ redhat

Re: noisy selinux messages on tmpfs mount.

[Paul Moore]

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.

[NOTE: adding the SELinux list to the CC line.]

-- 
paul moore
security @ redhat

Re: noisy selinux messages on tmpfs mount.

[Stephen Smalley]

We already reduced that message to KERN_DEBUG.  Is that not sufficient?

On Thu, Jan 8, 2015 at 2:39 PM, Paul Moore <pmoore@redhat.com> 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.
>
> [NOTE: adding the SELinux list to the CC line.]
>
> --
> paul moore
> security @ redhat
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

Re: noisy selinux messages on tmpfs mount.

[Stephen Smalley]

We already reduced that message to KERN_DEBUG.  Is that not sufficient?

On Thu, Jan 8, 2015 at 2:39 PM, Paul Moore <pmoore@redhat.com> 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.
>
> [NOTE: adding the SELinux list to the CC line.]
>
> --
> paul moore
> security @ redhat
>
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

Re: noisy selinux messages on tmpfs mount.

[Dave Jones]

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@redhat.com> 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.

	Dave

Re: noisy selinux messages on tmpfs mount.

[Dave Jones]

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@redhat.com> 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.

	Dave

Re: noisy selinux messages on tmpfs mount.

[Stephen Smalley]

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@redhat.com> 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.

Re: noisy selinux messages on tmpfs mount.

[Paul Moore]

On Friday, January 09, 2015 02:13:29 PM Dave Jones wrote:
> On Fri, Jan 09, 2015 at 08:06:49AM -0500, Stephen Smalley wrote:
>  > 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.

I wonder if this is cron/systemd/whatever creating a new namespace and 
mounting a new tmpfs in the namespace?  If yes, I wonder if we could limit the 
messages to the initial namespace ... ?

-- 
paul moore
security @ redhat

Re: noisy selinux messages on tmpfs mount.

[Paul Moore]

On Friday, January 09, 2015 02:13:29 PM Dave Jones wrote:
> On Fri, Jan 09, 2015 at 08:06:49AM -0500, Stephen Smalley wrote:
>  > 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.

I wonder if this is cron/systemd/whatever creating a new namespace and 
mounting a new tmpfs in the namespace?  If yes, I wonder if we could limit the 
messages to the initial namespace ... ?

-- 
paul moore
security @ redhat

Re: noisy selinux messages on tmpfs mount.

[Dominick Grift]

On Fri, 2015-01-09 at 15:55 -0500, Paul Moore wrote:
> On Friday, January 09, 2015 02:13:29 PM Dave Jones wrote:
> > On Fri, Jan 09, 2015 at 08:06:49AM -0500, Stephen Smalley wrote:
> >  > 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.
> 
> I wonder if this is cron/systemd/whatever creating a new namespace and 
> mounting a new tmpfs in the namespace?  If yes, I wonder if we could limit the 
> messages to the initial namespace ... ?
> 

It is systemd logind creating sessions (e.g. creating /run/user/$UID and
mounting a tmpfs on it)

Re: noisy selinux messages on tmpfs mount.

[Dominick Grift]

On Fri, 2015-01-09 at 15:55 -0500, Paul Moore wrote:
> On Friday, January 09, 2015 02:13:29 PM Dave Jones wrote:
> > On Fri, Jan 09, 2015 at 08:06:49AM -0500, Stephen Smalley wrote:
> >  > 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.
> 
> I wonder if this is cron/systemd/whatever creating a new namespace and 
> mounting a new tmpfs in the namespace?  If yes, I wonder if we could limit the 
> messages to the initial namespace ... ?
> 

It is systemd logind creating sessions (e.g. creating /run/user/$UID and
mounting a tmpfs on it)

Re: noisy selinux messages on tmpfs mount.

[Paul Moore]

systemd has taken over cron too?  I suppose that is a logical extension, 
but still...

--
paul moore
www.paul-moore.com



On January 9, 2015 4:01:29 PM Dominick Grift <dac.override@gmail.com> wrote:

> On Fri, 2015-01-09 at 15:55 -0500, Paul Moore wrote:
> > On Friday, January 09, 2015 02:13:29 PM Dave Jones wrote:
> > > On Fri, Jan 09, 2015 at 08:06:49AM -0500, Stephen Smalley wrote:
> > >  > 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.
> >
> > I wonder if this is cron/systemd/whatever creating a new namespace and
> > mounting a new tmpfs in the namespace?  If yes, I wonder if we could 
> limit the
> > messages to the initial namespace ... ?
> >
>
> It is systemd logind creating sessions (e.g. creating /run/user/$UID and
> mounting a tmpfs on it)
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: noisy selinux messages on tmpfs mount.

[Paul Moore]

systemd has taken over cron too?  I suppose that is a logical extension, 
but still...

--
paul moore
www.paul-moore.com



On January 9, 2015 4:01:29 PM Dominick Grift <dac.override@gmail.com> wrote:

> On Fri, 2015-01-09 at 15:55 -0500, Paul Moore wrote:
> > On Friday, January 09, 2015 02:13:29 PM Dave Jones wrote:
> > > On Fri, Jan 09, 2015 at 08:06:49AM -0500, Stephen Smalley wrote:
> > >  > 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.
> >
> > I wonder if this is cron/systemd/whatever creating a new namespace and
> > mounting a new tmpfs in the namespace?  If yes, I wonder if we could 
> limit the
> > messages to the initial namespace ... ?
> >
>
> It is systemd logind creating sessions (e.g. creating /run/user/$UID and
> mounting a tmpfs on it)
>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: noisy selinux messages on tmpfs mount.

[Dominick Grift]

On Fri, 2015-01-09 at 22:12 -0500, Paul Moore wrote:
> systemd has taken over cron too?  I suppose that is a logical extension, 
> but still...

That is were i think davej is wrong. Here is what i think is the
scenario with cron.

Cron runs jobs on behalf root. Root is generally not logged in all the
time. So every time cron performs a job on behalf of root (hourly etc),
systemd logind creates /run/user/0 and mounts tmpfs on it, when the job
is done, tmpfs is unmounted and /run/user/= removed.

In that sense cron acts as kind of a login program.

Where i think davej might be wrong is that this would also happen with
systemd's replacement for cron: timers.

I suspect that systemd logind does not create 0 user runtime directory
everytime a timer is triggered, as opposed to cron.

with regard to normal user timers.Those really only work if you enable
lingering on the systemd --user daemon with logind. This means that in
practice the user is always logged in from a systemd logind user runtime
directory point of view (e.g. /run/user/$UID is always there for a user
that has a lingering systemd session daemon instance)

In practice , i suspect that this means that, although now with cron
were seeing logind mount tmpfs whenever some job of behalf of root is
run if root is not physically loged in (which is often), that this would
not be the case if we got rid of cron and if it would be replaced by
systemd timers

One might ask the question: why does logind create a root user runtime
directory every time cron runs a job on behalf of root. Is that really
required?

> 
> --
> paul moore
> www.paul-moore.com
> 
> 
> 
> On January 9, 2015 4:01:29 PM Dominick Grift <dac.override@gmail.com> wrote:
> 
> > On Fri, 2015-01-09 at 15:55 -0500, Paul Moore wrote:
> > > On Friday, January 09, 2015 02:13:29 PM Dave Jones wrote:
> > > > On Fri, Jan 09, 2015 at 08:06:49AM -0500, Stephen Smalley wrote:
> > > >  > 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.
> > >
> > > I wonder if this is cron/systemd/whatever creating a new namespace and
> > > mounting a new tmpfs in the namespace?  If yes, I wonder if we could 
> > limit the
> > > messages to the initial namespace ... ?
> > >
> >
> > It is systemd logind creating sessions (e.g. creating /run/user/$UID and
> > mounting a tmpfs on it)
> >
> >
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

Re: noisy selinux messages on tmpfs mount.

[Dominick Grift]

On Fri, 2015-01-09 at 22:12 -0500, Paul Moore wrote:
> systemd has taken over cron too?  I suppose that is a logical extension, 
> but still...

That is were i think davej is wrong. Here is what i think is the
scenario with cron.

Cron runs jobs on behalf root. Root is generally not logged in all the
time. So every time cron performs a job on behalf of root (hourly etc),
systemd logind creates /run/user/0 and mounts tmpfs on it, when the job
is done, tmpfs is unmounted and /run/user/= removed.

In that sense cron acts as kind of a login program.

Where i think davej might be wrong is that this would also happen with
systemd's replacement for cron: timers.

I suspect that systemd logind does not create 0 user runtime directory
everytime a timer is triggered, as opposed to cron.

with regard to normal user timers.Those really only work if you enable
lingering on the systemd --user daemon with logind. This means that in
practice the user is always logged in from a systemd logind user runtime
directory point of view (e.g. /run/user/$UID is always there for a user
that has a lingering systemd session daemon instance)

In practice , i suspect that this means that, although now with cron
were seeing logind mount tmpfs whenever some job of behalf of root is
run if root is not physically loged in (which is often), that this would
not be the case if we got rid of cron and if it would be replaced by
systemd timers

One might ask the question: why does logind create a root user runtime
directory every time cron runs a job on behalf of root. Is that really
required?

> 
> --
> paul moore
> www.paul-moore.com
> 
> 
> 
> On January 9, 2015 4:01:29 PM Dominick Grift <dac.override@gmail.com> wrote:
> 
> > On Fri, 2015-01-09 at 15:55 -0500, Paul Moore wrote:
> > > On Friday, January 09, 2015 02:13:29 PM Dave Jones wrote:
> > > > On Fri, Jan 09, 2015 at 08:06:49AM -0500, Stephen Smalley wrote:
> > > >  > 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.
> > >
> > > I wonder if this is cron/systemd/whatever creating a new namespace and
> > > mounting a new tmpfs in the namespace?  If yes, I wonder if we could 
> > limit the
> > > messages to the initial namespace ... ?
> > >
> >
> > It is systemd logind creating sessions (e.g. creating /run/user/$UID and
> > mounting a tmpfs on it)
> >
> >
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

Re: noisy selinux messages on tmpfs mount.

[Dominick Grift]

On Sat, 2015-01-10 at 10:11 +0100, Dominick Grift wrote:
> On Fri, 2015-01-09 at 22:12 -0500, Paul Moore wrote:
> > systemd has taken over cron too?  I suppose that is a logical extension, 
> > but still...
> 
> That is were i think davej is wrong. Here is what i think is the
> scenario with cron.
> 
> Cron runs jobs on behalf root. Root is generally not logged in all the
> time. So every time cron performs a job on behalf of root (hourly etc),
> systemd logind creates /run/user/0 and mounts tmpfs on it, when the job
> is done, tmpfs is unmounted and /run/user/= removed.
> 
> In that sense cron acts as kind of a login program.
> 
> Where i think davej might be wrong is that this would also happen with
> systemd's replacement for cron: timers.
> 
> I suspect that systemd logind does not create 0 user runtime directory
> everytime a timer is triggered, as opposed to cron.
> 
> with regard to normal user timers.Those really only work if you enable
> lingering on the systemd --user daemon with logind. This means that in
> practice the user is always logged in from a systemd logind user runtime
> directory point of view (e.g. /run/user/$UID is always there for a user
> that has a lingering systemd session daemon instance)
> 
> In practice , i suspect that this means that, although now with cron
> were seeing logind mount tmpfs whenever some job of behalf of root is
> run if root is not physically loged in (which is often), that this would
> not be the case if we got rid of cron and if it would be replaced by
> systemd timers
> 
> One might ask the question: why does logind create a root user runtime
> directory every time cron runs a job on behalf of root. Is that really
> required?
> 

Never the less. On systems with many users login and out regularly you
will see this message often. because when a user logs in /run/user/$UID
is created and tmpfs is mounted on it. When the user logs out tmpfs is
unmounted, and /run/user/$UID is removed ... unless that users' systemd
--user instance is lingering.

> > 
> > --
> > paul moore
> > www.paul-moore.com
> > 
> > 
> > 
> > On January 9, 2015 4:01:29 PM Dominick Grift <dac.override@gmail.com> wrote:
> > 
> > > On Fri, 2015-01-09 at 15:55 -0500, Paul Moore wrote:
> > > > On Friday, January 09, 2015 02:13:29 PM Dave Jones wrote:
> > > > > On Fri, Jan 09, 2015 at 08:06:49AM -0500, Stephen Smalley wrote:
> > > > >  > 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.
> > > >
> > > > I wonder if this is cron/systemd/whatever creating a new namespace and
> > > > mounting a new tmpfs in the namespace?  If yes, I wonder if we could 
> > > limit the
> > > > messages to the initial namespace ... ?
> > > >
> > >
> > > It is systemd logind creating sessions (e.g. creating /run/user/$UID and
> > > mounting a tmpfs on it)
> > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> > 
> 
> 

Re: noisy selinux messages on tmpfs mount.

[Dominick Grift]

On Sat, 2015-01-10 at 10:11 +0100, Dominick Grift wrote:
> On Fri, 2015-01-09 at 22:12 -0500, Paul Moore wrote:
> > systemd has taken over cron too?  I suppose that is a logical extension, 
> > but still...
> 
> That is were i think davej is wrong. Here is what i think is the
> scenario with cron.
> 
> Cron runs jobs on behalf root. Root is generally not logged in all the
> time. So every time cron performs a job on behalf of root (hourly etc),
> systemd logind creates /run/user/0 and mounts tmpfs on it, when the job
> is done, tmpfs is unmounted and /run/user/= removed.
> 
> In that sense cron acts as kind of a login program.
> 
> Where i think davej might be wrong is that this would also happen with
> systemd's replacement for cron: timers.
> 
> I suspect that systemd logind does not create 0 user runtime directory
> everytime a timer is triggered, as opposed to cron.
> 
> with regard to normal user timers.Those really only work if you enable
> lingering on the systemd --user daemon with logind. This means that in
> practice the user is always logged in from a systemd logind user runtime
> directory point of view (e.g. /run/user/$UID is always there for a user
> that has a lingering systemd session daemon instance)
> 
> In practice , i suspect that this means that, although now with cron
> were seeing logind mount tmpfs whenever some job of behalf of root is
> run if root is not physically loged in (which is often), that this would
> not be the case if we got rid of cron and if it would be replaced by
> systemd timers
> 
> One might ask the question: why does logind create a root user runtime
> directory every time cron runs a job on behalf of root. Is that really
> required?
> 

Never the less. On systems with many users login and out regularly you
will see this message often. because when a user logs in /run/user/$UID
is created and tmpfs is mounted on it. When the user logs out tmpfs is
unmounted, and /run/user/$UID is removed ... unless that users' systemd
--user instance is lingering.

> > 
> > --
> > paul moore
> > www.paul-moore.com
> > 
> > 
> > 
> > On January 9, 2015 4:01:29 PM Dominick Grift <dac.override@gmail.com> wrote:
> > 
> > > On Fri, 2015-01-09 at 15:55 -0500, Paul Moore wrote:
> > > > On Friday, January 09, 2015 02:13:29 PM Dave Jones wrote:
> > > > > On Fri, Jan 09, 2015 at 08:06:49AM -0500, Stephen Smalley wrote:
> > > > >  > 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.
> > > >
> > > > I wonder if this is cron/systemd/whatever creating a new namespace and
> > > > mounting a new tmpfs in the namespace?  If yes, I wonder if we could 
> > > limit the
> > > > messages to the initial namespace ... ?
> > > >
> > >
> > > It is systemd logind creating sessions (e.g. creating /run/user/$UID and
> > > mounting a tmpfs on it)
> > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> > 
> 
> 

Re: noisy selinux messages on tmpfs mount.

[Christopher J. PeBenito]

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@redhat.com> 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?

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Re: noisy selinux messages on tmpfs mount.

[Paul Moore]

On Monday, January 12, 2015 09:51:17 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:
> >> 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)?

I'm pretty sure Stephen just meant the normal case, not the "unknown behavior" 
case.

> Is there going to be another place to look see what the labeling behavior is
> for all mounted filesystems?

I imagine we could create something in securityfs for that, you want to write 
a patch Chris? :)

-- 
paul moore
security @ redhat

Re: noisy selinux messages on tmpfs mount.

[Paul Moore]

On Monday, January 12, 2015 09:51:17 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:
> >> 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)?

I'm pretty sure Stephen just meant the normal case, not the "unknown behavior" 
case.

> Is there going to be another place to look see what the labeling behavior is
> for all mounted filesystems?

I imagine we could create something in securityfs for that, you want to write 
a patch Chris? :)

-- 
paul moore
security @ redhat

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@redhat.com> 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.