[systemd-devel] TTY ownership and systemd user session

Lennart Poettering lennart at poettering.net
Mon Jan 20 08:49:53 PST 2014


On Fri, 10.01.14 14:11, Yin Kangkai (kangkai.yin at linux.intel.com) wrote:

> 
> On 2014-01-10, 06:27 +0100, Lennart Poettering wrote:
> > On Thu, 09.01.14 09:56, Yin Kangkai (kangkai.yin at linux.intel.com) wrote:
> > 
> > > Hi,
> > > 
> > > I am bringing up systemd user session in Tizen, I am using v208.
> > > 
> > > We run into a small issue that if a user session service file claims
> > > TTY, systemd user session will fail to chown_terminal() for it:
> > > 
> > >  "Failed at step STDIN spawning /usr/bin/xorg-launch-helper: Permission denied"
> > > 
> > > My testing service file has something like this:
> > > 
> > >   [Service]
> > >   StandardInput=tty
> > >   TTYPath=/dev/tty1
> > >   ExecStart=/usr/bin/xxx
> > > 
> > > 
> > > I tried to look into the code...  The failure seems happen after
> > > "systemd --user" forked and about the exec into the new process, in
> > > execute.c:exec_spawn(), when calling chown_terminal().
> > > 
> > > So my question is:
> > > 
> > >  * does systemd depend on other (e.g. udev) to set the /dev/tty1
> > >    permission beforehand? Or
> > > 
> > >  * should we do the chown_terminal() stuff in PAM/pam_systemd after we
> > >    got the PAM_TTY? since otherwise it's too late to do it in
> > >    exec_spawn(), it's already running as normal "user", you can't
> > >    chown /dev/tty1 etc.
> > > 
> > > Please help me to understand this, and anything I am missing. Thanks.
> > 
> > The chown_terminal() call is invoked at  point in time where privileges
> > have not been dropped yet for the process that is being forked off. This
> > means that there isn't actually relly any excuse for ths to fail with
> > EPERM, since we are still root.
> 
> No? It is already in user session, systemd is not root here any more
> right? Do I miss anything?

Oh sorry, I missed that this was about the user session. 

When systemd runs with "--user" it is an unprivileged process like any
other. This means that access to /dev/tty1 is granted by the OS based on
the file access mode and ACL of the /dev/tty1 device node. If you want
to run a user service likes this you hence need to somehow make sure the
device node is chowned properly or got the right ACLs assigned...

Lennart

-- 
Lennart Poettering, Red Hat


More information about the systemd-devel mailing list