[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1420881869.24061.17.camel@gmail.com>
Date: Sat, 10 Jan 2015 10:24:29 +0100
From: Dominick Grift <dac.override@...il.com>
To: Paul Moore <paul@...l-moore.com>
Cc: Paul Moore <pmoore@...hat.com>,
Dave Jones <davej@...emonkey.org.uk>,
Stephen Smalley <sds@...ch.ncsc.mil>,
James Morris <james.l.morris@...cle.com>,
selinux <selinux@...ho.nsa.gov>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: noisy selinux messages on tmpfs mount.
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@...il.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@...r.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > Please read the FAQ at http://www.tux.org/lkml/
> >
> >
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists