Date: Wed, 7 Nov 2001 22:18:46 +0100 (CET)
From: Ronald Kuehn <rk@ronald.org>
To: freebsd-arch@FreeBSD.ORG
Subject: Re: /etc/ttys, /var/run/utmp, ttyslot(3) and {get|put}utx* API
Message-ID: <200111072118.fA7LIkm00435@wallace.home.ronald.org>
References: <15786.1004869680@critter.freebsd.dk> <Pine.NEB.3.96L.1011107074837.14344B-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In freebsd-arch, Robert Watson <rwatson@FreeBSD.ORG> wrote:
> On Sun, 4 Nov 2001, Poul-Henning Kamp wrote:
> > While thinking about the new cloning behaviour of the PTY driver, my
> > attention again crossed the /etc/ttys vs /var/run/utmp mess.
> >
> > Briefly speaking, all tty devices must be prelisted in /etc/ttys, if
> > they are not, no record will be made in /var/run/utmp and consequently,
> > the user will not show up in who(1).
> >
> > This is a minor security issue.
> >
> > A particular tty's entry in /var/run/utmp is determined by its index in
> > the /etc/ttys file, so if you edit /etc/ttys and change the order,
> > insert or delete a record, you screw up your /var/run/utmp.
> >
> > This is just ugly.
> >
> > To complicate matters, some sessions, like ftp, rsync, scp, ppp and so
> > on should also be registered, but are not reliably so.
> >
> > This is just sloppy, and a minor security hazzle.
> >
> > I guess the correct solution is to implement the Single Unix
> > "{get|put}utx" API backed by a db(3) file.
> >
> > http://www.opengroup.org/onlinepubs/007908799/xsh/endutxent.html
> >
> > Any comments ?
> "Yet another thread-unsafe API for managing databases"? If we do
> implement this, we should really implement the _r versions which
> presumably exist on thread-aware platforms. However, a little inspection
> of my local Solaris box reveals that they don't have a thread-safe version
> either:
> ____________________________________________________________
> | ATTRIBUTE TYPE | ATTRIBUTE VALUE |
> |_____________________________|_____________________________|
> | MT-Level | Unsafe |
> |_____________________________|_____________________________|
> The Solaris man page also comments:
> These functions use buffered standard I/O for input, but
> pututxline() uses an unbuffered write to avoid race condi-
> tions between processes trying to modify the utmpx and wtmpx
> files.
> With a db file, we'd probably have to make use of appropriate locking.
> The Solaris version actually supports a more broad set of calls that
> allows the caller a seperate interface to identify the target utmp file.
> It would be interesting to know if any applications use it.
> On occasion, I've wondered if this information couldn't be stored
> in-kernel and managed using calls similar to get/setlogin(). However,
> that fails to address a variety of scoping issues, and is probably a bad
> idea given that "logged in" is a userland concept, not a kernel concept.
> However, this API still requires privilege (directly or indirectly) to
> modify the database, and potentially a kernel interface wouldn't (subject
> to some authorization procedures, presumably -- logged username must ==
> process login name, et al). For applications like xterm, it would be nice
> if privilege was not required -- presumably with improved devfs support
> for pty's, it will no long be required for that.
> This isn't an objection, just some observations on implementation. Go
> with the db idea if you have time to implement it :-).
Hi,
a long time ago I implemented a mechanism for changing ownership of
ptys in the style used by Solaris or Tru64 Unix using a helper program.
Please have a look at PR 9770. I don't know if this is still needed
for devfs. It only solves half the problem: Applications don't need
to be setuid root just for providing pseudo ttys. Unfortunately,
the utmp problem still exists. One way to fix this would be to
use something like the SUSv2 described mechanism as described above.
I don't think that this can be solved in a clean way w/o kernel support.
If non-root processes are allowed to make entries in a utmp-style
database, certain risks must be considered:
(1) Make sure a process can only make entries for terminals it really owns.
(2) How to get rid of out-of-date entries when the processes that made them
"forgot" to remove them?
Problem (2) usually does not occure on systems that only allow root-processes
to make those entries. Those programs can be inspected and are under control
of the system administrator or vendor. When normal user processes (like
screen) are allowed to make such entries their removal cannot be assured since
any user can install them.
Maybe some deamon could get information from the kernel when a pseudo
terminal is closed. It could then assure that the utmp entry gets removed.
Bye,
Ronald
--
* The whole problem with the world is that fools and fanatics are always
* so certain of themselves, but wiser people so full of doubts.
* --Bertrand Russell
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200111072118.fA7LIkm00435>