This is the mail archive of the
libc-alpha@cygnus.com
mailing list for the glibc project.
Re: ut_id questions
On Wed, Apr 28, 1999 at 10:42:08PM +0200, Mark Kettenis wrote:
> Here is my try at giving the right answer. This is what I have always
> kept in mind when I was (re)implementing the utmp functions in glibc.
>
> For all processes that are started by `init' the `ut_id' member should
...
> procedure.
Right. For these, I understand. ut_id gets propogated along the chain
of controlling processes.
> Another large class of processes that add entries to the user
> accounting database, are processes that use pseudo terminals, for
> example xterm and telnetd. For BSD pseudo terminals the
> ``tty-suffix'' rule has been used for a long time. This makes sense
> since BSD pseudo terminals have names like `ttyp1', which fit nicely
> into this scheme.
Right...
> However the new Unix98 pseudo terminal names do not fit in. We should
> probably look at Solaris at how to handle these, but I could not
> discover a ``rule''. For example, `telnetd' seems to behave
> differently from `xterm'. But maybe somebody else could have a look
> at it and discover a the ``rule'' that Solaris uses.
>
> Since a lot of programs implement the ``tty-suffix'' rule by stripping
> the first six characters from the device name, the Unix98 names often
(you mean eight, no?)
> end up like "/23" (/dev/pts/23). However this breaks down if one uses
> more than 999 pseudo terminals, since `ut_id' is only four characters
> long.
True. We need to decide if we want to handle this case at all.
> I should add, that for compatibility with BSD (which does not have an
> `ut_id' field) the glibc version of getutxid() is a bit more
> forgiving, and if `ut_id' is not set, it searches for a matching
> `ut_line' instead.
>
> This makes it possible to leave `ut_id' empty for devices that do not
> start with '/dev/tty', and set `ut_line' instead when using
> getutxid(), and makes your programs less vulnerable if other people
> make the wrong choices.
Sure, but that isn't the current situation; programs are filling in the
field, but inconsistently.
Let's see... this is what Solaris showed me. The left is ut_id, and
the right is ut_line. The / notation appears a few times, and tn??
notation is sequential through utmp irregardless of the order of the
ptys, so probably some daemon is responsible for all of those.
/2 | pts/2
/4 | pts/4
tn30 | pts/3
rl10 | pts/9
tn40 | pts/5
/5 | pts/5
/6 | pts/6
tn50 | pts/6
tn60 | pts/10
/1 | pts/1
/8 | pts/8
tn70 | pts/10
tn80 | pts/8
On Linux right now, I see this:
8 | tty8
9 | tty9
/5 | pts/5
/6 | pts/6
p0 | ttyp0
P004 | pts/4
P005 | pts/5
Ahah! On systems where ssh's configure script detects utmpx, it
assumes /dev/pts, and determines ut_id like so:
if (stat(ttyname, &st) == 0) {
/* allow for 1000 /dev/pts devices */
sprintf(buf, "P%03d", (int)minor(st.st_rdev));
}
strncpy(ux.ut_id, buf, sizeof(ux.ut_id));
This is the closest I have yet seen to a good solution. It fails with
/dev/pts/1000, however.
I have a proposal for this.
First, I would like to propose a macro in glibc headers, which could be
easily autoconf'd, which creates a ut_id field from a ut_line for
pseudo-terminals.
Second, I would like to suggest a format for /dev/pts PTYs' ut_ids.
For the first thousand, use Pxxx, and for the next nine thousand, just
xxxx. This keeps them human-readable, and no other method of
pseudottys I know of supports that many.
I would love to see someone define a "right" way to do this! If it is
not used at all, it does no harm, but it is being used inconsistently,
and that is worse.
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| CMU, CS class of 2002 |
| Debian GNU/Linux Developer __ Part-Time Systems Programmer |
| dan@debian.org | | drow@cs.cmu.edu |
\--------------------------------/ \--------------------------------/