[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /var/run/utmp



In article <cistron.19990315234437.C26341@ecn.purdue.edu>,
Branden Robinson  <branden@ecn.purdue.edu> wrote:
>On Mon, Mar 15, 1999 at 04:16:17PM -0800, Joel Klecker wrote:
>> There is another reason for utmpd, and that's to allow programs to=20
>> write utmp entries without needing to be suid root.
>> In any event, due to the distressingly large number of programs that=20
>> manipulate the utmp and wtmp files directly, I am getting rid of=20
>> utmpd in the next release.
>
>NO!!!!!
>
>Really, please put it back soon.  It's time to migrate.  It's *BAD* to have
>stuff sitting around setuid root just so it can muck with the utmp file.

Well. Guess what. You need to be root to be able to open the UNIX domain
socket and talk to utmpd ... I just read the source of utmpd.

>Miquel van Smoorenburg is cool and I respect his opinion, but in the end
>life will be better with Unix98 pty handling.
>Of course, I speak from a biased position, since I package xterm, and I
>desperately want to get rid of its setuid bit.

You can't even with utmpd. Suid programs will still be needed, alas.
Well, unless you write an external suid program that is called by the
library function pututline(). But in that case, why bother with utmpd ?
That external program could manipulate /var/run/utmp directly.

When everyone is running a Linux kernel > 2.2, one should be able
to use getsockopt(SO_GETCREDS) but that's Linux-only and only really
feasible in 1 or 2 years, not right now.

In fact do we really want all unpriviliged programs to be able to muck
around with the utmp and wtmp files? Actually, on my system, I would
not want that. But we're not discussing that right now.

So anyway, I still see no need for utmpd ..

In fact, judging from README.utmpd from the glibc 2.1 sources I think we're
better off without it. Things like:

  If the file `/var/log/wtmp' exists on your system, you will probably
  want to create the file `/var/log/wtmpx'.  Programs linked against the
  GNU C Library will now write to `/var/log/wtmpx', while programs
  linked against the old library will continue to write to
  `/var/log/wtmp'.  Of course this means that the information gets
  spread over two files.  We hope to provide a better solution in the
  future.

Don't sound too good ...

Mike.
-- 
Indifference will certainly be the downfall of mankind, but who cares?


Reply to: