Date: Mon, 23 May 2011 09:40:59 +0100 From: Chris Rees <utisoft@gmail.com> To: utisoft@gmail.com Cc: Ed Schouten <ed@80386.nl>, freebsd-ports@freebsd.org Subject: Re: Utmpx usage Message-ID: <BANLkTi=XCcOCs4zrVPYHzimzzpPJ34jXNg@mail.gmail.com> In-Reply-To: <BANLkTikpxDeE0CnALF22eiYXvuuOLkjsQw@mail.gmail.com> References: <BANLkTimVF_YgdJ_d6=-L5jmx_zVrbp0wBQ@mail.gmail.com> <20110522205003.GH59496@hoeg.nl> <BANLkTikpxDeE0CnALF22eiYXvuuOLkjsQw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23 May 2011 09:30, "Chris Rees" <utisoft@gmail.com> wrote: > > On 22 May 2011 21:50, Ed Schouten <ed@80386.nl> wrote: > > Hi Chris! > > > > * Chris Rees <utisoft@gmail.com>, 20110522 09:29: > >> Hi all, > >> > >> After removing all kittens from Ed's reach, I'm disclosing that > >> sysutils/runit tried to use utmpx to directly read() and write() the > >> utmpx files directly... > >> > >> I've replaced the offending code with a patch to the port [1], but I > >> wonder if anyone would please review the patch? I don't have a CURRENT > >> machine to try it on... I may have also made some terrible mistakes -- > >> I'm not hugely familiar with utmpx. > >> > >> Thanks! > >> > >> Chris > >> > >> [1] http://www.bayofrum.net/~crees/patches/runit-utmpx.patch > > > > As promised, I would look at your patch this evening. I've changed the > > cc to ports@, since it's likely a better place to discuss this. > > > > First of all, you can remove the getutxent()/endutxent() calls; at least > > on FreeBSD (but even on Solaris -- the first OS to implement utmpx) > > pututxline() is implemented separately from the read-functions. There is > > no need to open the database for reading. > > > > Secondly, please make sure you set the proper fields of the utmpx > > structure. Always zero it (e.g. with memset()) before calling > > pututxline() to prevent random junk from ending up in the log files. > > Also, for DEAD_PROCESS must we set ut_id, but not ut_line. ut_id must be > > set to one of the identifiers of an existing session. These identifiers > > can be set to arbitrary values by the application that added the entry. > > Some apps are lazy and just put the TTY name in there, but you cannot > > assume that that's the case. Run `getent utmpx active' to see what the > > identifiers look like. For example, pam_lastlog(8) uses random > > identifiers. You must also set ut_tv, even though our implementation > > does it for you. > > > > Finally, I'm not really sure what the code is trying to solve here. > > What's the use of implementing an utmp_logout(), to simulate logouts on > > the utmp database, without actually providing code to perform logins? > > Maybe we should just patch runit to leave utmp(x) alone. So far I don't > > have a feeling it's trying to do something useful with it. > > > > > Thanks for the pointers! I'll get those in. > > The code is for a utility for recording logouts in utmp(x) [1] -- > there's no facility provided for utmp logins. > > Perhaps we should just comment out the code and leave utmpset as unimplemented. I've been perusing the linux manpage for utmp, and noticed that login and getty deal with utmp for logins, and It's only init's job to deal with logouts. Since runit is an init replacement, this makes perfect sense. > Chris > > [1] http://smarden.org/runit/utmpset.8.html
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BANLkTi=XCcOCs4zrVPYHzimzzpPJ34jXNg>