Date: Wed, 7 Nov 2001 07:58:30 -0500 (EST)
From: Robert Watson <rwatson@freebsd.org>
To: Poul-Henning Kamp <phk@freebsd.org>
Cc: arch@freebsd.org
Subject: Re: /etc/ttys, /var/run/utmp, ttyslot(3) and {get|put}utx* API
Message-ID: <Pine.NEB.3.96L.1011107074837.14344B-100000@fledge.watson.org>
In-Reply-To: <15786.1004869680@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :-).
Robert N M Watson FreeBSD Core Team, TrustedBSD Project
robert@fledge.watson.org NAI Labs, Safeport Network Services
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?Pine.NEB.3.96L.1011107074837.14344B-100000>