lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 10 Jan 2015 10:11:25 +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 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@...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

Powered by Openwall GNU/*/Linux Powered by OpenVZ