utmp daemon

utmp daemon

[Nicolas George]

[-- Attachment #1: Type: text/plain, Size: 2463 bytes --]

We probably all know what utmp. Yet, I will remind it in a few words.

utmp is a file where are listed (in a binary form suitable to be loaded
directly in a C structure) all "people" "using" the system. People using
the system means mostly logged in users, but there may be utmp entries
for X11 sessions, or FTP clients.

There are two problems with such a design. First, it relies on programs
to de-register themselves from the utmp, and anyone knows it just does
not work: start an xterm, kill-9 it, and you have a stale utmp entry.
Second, it requires that all programs needing to register themselves are
SGID utmp, which is not really good for security, and quite bad for task
delegations (I can't install a new version of xterm or screen unless I
am root).

The solution, I believe, is a deamon listening on an Unix-domain socket.
Each program that want to register itself connect()s itself to that
socket. If the program dies, the daemon sees the socket closed and can
clean up. For a pseudo-tty line, the process holding the utmp socket is
obvious: it is the pseudo-terminal master. For real tty line, the
current common scheme where login exec()s into the login shell must be
somehow changed (the way to do it is not so obvious, since we still want
the login shell to be session leader on its tty, but it is possible).

Well, there is nothing really original there. But I had one more idea:
the whole point of utmp is for processes to advertise their presence and
their status, and I believe there is no reason to use this facility only
for interactive processes like ssh sessions: daemons also needs to
advertise themselves.

There is a problem with daemons dependencies: there may be some time
between the instant one type "/some/daemon &" and the instant the daemon
is ready (listening on its socket or whatever). utmp may be used for
daemons to advertise that they are ready. The utmp daemon could even
forward status change notifications to interested clients.

I realize such a daemon does not meet the minimalistic tastes of some
people around here: dependency handling of daemons startup can be done
with pipes, and so on. But yet, reliable utmp can not be done with just
pipes, and if there is a daemon there to do that, I think it is no bloat
tu use it at the best of what it can do.

I will stop here for this mail. I have some pore precise ideas about the
implementation details, but I will not tell them unless someone shows
he's interested.

[-- Attachment #2: Type: application/pgp-signature, Size: 185 bytes --]

Re: utmp daemon

[Clemens Fischer]

* Nicolas George:

> There is a problem with daemons dependencies: there may be some time
> between the instant one type "/some/daemon &" and the instant the daemon
> is ready (listening on its socket or whatever). utmp may be used for
> daemons to advertise that they are ready. The utmp daemon could even
> forward status change notifications to interested clients.

well i think people might well be interested in solvong the dependancy
problem, especially in the generel context you're talking about.  to let
login shells be session leader, there may not be such a big problem if you
splice in an extra exec(2) for a little program connecting to an utmp (or
whatever) daemon.  if this little program can be easily verified security-
wise, people won't hesitate to run it suid utmp, i guess.

  clemens

Re: utmp daemon

[Paul Jarc]

"Clemens Fischer" <ino-qc@spotteswoode.de.eu.org> wrote:
> there may not be such a big problem if you splice in an extra
> exec(2) for a little program connecting to an utmp (or whatever)
> daemon.  if this little program can be easily verified security-
> wise, people won't hesitate to run it suid utmp, i guess.

If it connects to a socket instead of recording utmp entries directly,
then it won't need to be setgid anyway.


paul

Re: utmp daemon

[Clemens Fischer]

* Paul Jarc:

> "Clemens Fischer" <ino-qc@spotteswoode.de.eu.org> wrote:
>> there may not be such a big problem if you splice in an extra exec(2)
>> for a little program connecting to an utmp (or whatever) daemon.  if
>> this little program can be easily verified security- wise, people won't
>> hesitate to run it suid utmp, i guess.
>
> If it connects to a socket instead of recording utmp entries directly,
> then it won't need to be setgid anyway.

right.

  clemens

Re: utmp daemon

[Nicolas George]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

Le duodi 22 floréal, an CCXII, Clemens Fischer a écrit :
> well i think people might well be interested in solvong the dependancy
> problem, especially in the generel context you're talking about.

Alas, it can only solve anything if the daemon upon which one depends
registers itself. Any "mainstream" daemon would have to be patched to do
that.

>								   to let
> login shells be session leader, there may not be such a big problem if you
> splice in an extra exec(2) for a little program connecting to an utmp (or
> whatever) daemon.

I do not really see the design you suggest. There must be a process to
hold the socket to the utmp daemon. We can not rely on the user and let
the socket in the file descriptors of the login shell. The best place,
then, is probably in getty/login respawner. This requires to adapt login
so it notifies its parent that the user is successfully logged in, or
that he itself notifies the utmp deamon, before closing its copy of the
socket. Well, these are only details.

[-- Attachment #2: Type: application/pgp-signature, Size: 185 bytes --]

Re: utmp daemon

[Clemens Fischer]

* Nicolas George:

> Le duodi 22 floréal, an CCXII, Clemens Fischer a écrit :
>> well i think people might well be interested in solvong the dependancy
>> problem, especially in the generel context you're talking about.
>
> Alas, it can only solve anything if the daemon upon which one depends
> registers itself. Any "mainstream" daemon would have to be patched to do
> that.

yes, this is clear to me.  i'd expect your proposed framework to be used in
the djb-services arena first, as people have expressed interest in solving
the "dependancy-problem".

>> login shells be session leader, there may not be such a big problem if
>> you splice in an extra exec(2) for a little program connecting to an
>> utmp (or whatever) daemon.
>
> I do not really see the design you suggest. There must be a process to
> hold the socket to the utmp daemon.

i thought something along the lines of getty -> wrapper -> login, with
wrapper beeing the customary "wrapper <options> login".  login is
execve(2)ed by the wrapper and does only the connecting to the utmp-
daemon.  for this purpose it keeps the socket you propose.

> We can not rely on the user and let the socket in the file descriptors of
> the login shell. The best place, then, is probably in getty/login
> respawner. This requires to adapt login so it notifies its parent that
> the user is successfully logged in, or that he itself notifies the utmp
> deamon, before closing its copy of the socket.

isn't this what i described?  note that quite a few people run G. Papes
http://smarden.org/runit/ as i'm sure you are aware of, which might be the
place to use this wrapper.  i hope i got this right.  should login(1) fail,
the wrapper will notice automatically.  isn't this enough?

  clemens

Re: utmp daemon

[Laurent Bercot]

> i thought something along the lines of getty -> wrapper -> login, with
> wrapper beeing the customary "wrapper <options> login".  login is
> execve(2)ed by the wrapper and does only the connecting to the utmp-
> daemon.  for this purpose it keeps the socket you propose.

 The problem with that approach is that children processes get an open
fd they're not aware of. Most of the time, this doesn't hurt; but
it does when you're trying to "nohup" something, log off, and let
something run in the background. Your process tree, starting at getty,
must know what is an "interactive" session, using the utmp connection,
and what is a process that doesn't count for the utmp and should have
the utmp fd closed. There is no way to transmit that information.

 Some "login" programs fork, exec, and the parent stays in memory the
whole session long, just to keep utmp information ; when the child dies,
the parent records a log off. This is ugly - it means that a process
does nothing but wait for its child, only to do something when the
child dies. I'd like to do better, but just an open fd to some utmp
daemon won't do, because you'd need something like "close-on-fork" for
it to work properly.

-- 
 Ska

Re: utmp daemon

[Gerrit Pape]

On Tue, May 11, 2004 at 06:31:44PM +0200, Clemens Fischer wrote:
> * Nicolas George:
> > Le duodi 22 flor??al, an CCXII, Clemens Fischer a ??crit??:
> >> well i think people might well be interested in solvong the dependancy
> >> problem, especially in the generel context you're talking about.
> > Alas, it can only solve anything if the daemon upon which one depends
> > registers itself. Any "mainstream" daemon would have to be patched to do
> > that.
> yes, this is clear to me.  i'd expect your proposed framework to be used in
> the djb-services arena first, as people have expressed interest in solving
> the "dependancy-problem".

I personally don't have a "dependency-problem", and have yet to see an
example of one that is not actually a problem of a specific service
daemon.  There are solutions to work around the service daemon's
problems until they get fixed.

But I found the utmp/utmpx/wtmp thing a mess when working with it, and
would be interested in a cross-platform replacement.  I worry about
backwards compatibility with current services though.  Nicolas, if
you're interested take a look at the fgetty/checkpassword/login package
from fefe, the utmpset program, and how runit handles getty services.
They address some of the problems you describe.

Regards, Gerrit.

Re: utmp daemon

[Nicolas George]

[-- Attachment #1: Type: text/plain, Size: 1380 bytes --]

Le sextidi 26 floréal, an CCXII, Gerrit Pape a écrit :
> But I found the utmp/utmpx/wtmp thing a mess when working with it, and
> would be interested in a cross-platform replacement.  I worry about
> backwards compatibility with current services though.

You are right, programs which relies on the actual file /var/run/utmp to
be up to date must keep running. I guess we could rely on the daemon to
update the file if necessary. This would even make the content of the
file a little bit more reliable, for lusers can not kill the daemon,
while they can kill xterm.

>							Nicolas, if
> you're interested take a look at the fgetty/checkpassword/login package
> from fefe, the utmpset program, and how runit handles getty services.
> They address some of the problems you describe.

As far as I can tell, their approach is classical. The point is that in
the file-based utmp, staying registered is a passive operation, while
registering and unregistering are active. That means the login system
can register the line in utmp, and then exec() into the user shell,
which will stay registered. In a daemon-based implementation, stying
registered is an active action (keeping a socket open), so the
architecture can not be the same at all.

I think I will soon write a more detailed description of the
architecture and API I think of after this discussion.

[-- Attachment #2: Type: application/pgp-signature, Size: 185 bytes --]

Re: utmp daemon

[Gerrit Pape]

On Mon, May 17, 2004 at 12:49:06PM +0200, Nicolas George wrote:
> Le sextidi 26 flor?al, an CCXII, Gerrit Pape a ?crit?:
> > you're interested take a look at the fgetty/checkpassword/login package
> > from fefe, the utmpset program, and how runit handles getty services.
> > They address some of the problems you describe.
> 
> As far as I can tell, their approach is classical. The point is that in

Yes, they use the current interface, but they show some weaknesses of
the current utmp concept you mentioned, and work around them.

fgetty, while using the checkpassword interface to authenticate login,
does the trick of passing an open filedescriptor down the process chain
to write an utmp record when privileges are already dropped.  utmpset
separates the task of cleaning up utmp records from init, so you could
use it for other services than getties also, through the ./finish
scripts.  Do you see a problem in how runit handles getty services and
its utmp records?

> I think I will soon write a more detailed description of the
> architecture and API I think of after this discussion.
Good, thanks.

Regards, Gerrit.