SDTLOGIN interface

[Glynn Clements]

Edgar Toernig wrote:

> > When the X server starts, it creates a named pipe (aka fifo) in a
> > directory writable only by root.  The display manager opens the other
> > end of this pipe for writing.   Once it's displayed the login screen
> > and authenticated a user, the display manager writes a series of
> > key value pairs over the pipe such as:
> > 	
> >        UID="123" GID="10";
> >        G_LIST_ID="1" G_LIST_ID="2" G_LIST_ID="3";
> >        HOME="/home/bob" EOF="";
> > 
> > Once it sees the EOF="" token, the Xserver closes the pipe and
> > processes the other pairs - approximately:
> > 	setregid(GID)
> > 	setgroups(G_LIST_ID list)
> > 	chown(server-auth-file, UID)
> > 	setreuid(UID)
> > 	chdir(HOME)
> 
> What's the point in all this ... stuff?
> 
> Why should the X-server run with the privileges of some
> arbitrary user?

It's not an "arbitrary" user, it's the user who is actually using the
X server.

> Why should it be able to read some user's mail, have access to its
> crontab etc?

Arguably, any file access should be done with the permissions of the
user on whose behalf the server is running, so that e.g. 
XSetFontPath() behaves sanely.

> And what if that user happens to be root?

Then the X server runs as root, which is typically the case if you
don't have the above ... stuff.

> I do understand that one wants to drop all privileges as
> soon as possible but doesn't that mean to switch to the
> least privileged account, something like 'nobody'?

That would mean that processes running as "nobody" can kill() the X
server, but the logged-in user cannot. Also, the user would be unable
to add private directories to the font path (well, they could add
them, but the X server wouldn't be able to read them).

There may well be other, similar issues, but the main point is to have
the X server owned by the user on whose behalf it is operating.

Having to start the X server as root is an artifact of it having been
written for OS kernels which didn't include drivers for the video
hardware, meaning that the server needed direct hardware access, so it
had to run as root. If it wasn't for that issue, the server could just
run as a normal user from the outset.

-- 
Glynn Clements <glynn at gclements.plus.com>