Re: locking utmp
On Tue, Mar 19, 2002 at 07:58:54PM +0100, Russell Coker wrote:
> On Tue, 19 Mar 2002 17:46, Steve Langasek wrote:
> > > If it keeps the read lock for an extended period of time and locks out
> > > other processes then it could allow a local DOS attack.
> >
> > AFAIK, read locks are not exclusive.
> But they block processes from writing. If you could use that to stop other
> people logging in...
Well, there is that..
> > > > If the question is really "why does it want a read lock at all?", I
> > > > don't think I have an answer for that one.
> > > Getting a read lock on the utmp file before reading it is reasonable.
> > > Not sure why it needs to read it at all though. Must be something in
> > > PAM.
> > Probably a 'session .* pam_unix.so' line in the PAM config for this
> > module. Consensus among PAM developers is that utmp is the closest
> > possible definition for a 'unix session', so calling the session
> > management functions of the pam_unix functions writes to utmp.
> Session shouldn't even apply as the program in question only checks the
> password. Maybe the auth line for pam_unix.so is doing it.
Looking at the source to the Debian pam package, I seem to be
misremembering; the only references to utmp in pam_unix are in a
PAM_getlogin() helper function that's called to log the logged-in
username associated with failed authentication attempts. I see that
pam_limits also looks in utmp to count the number of open sessions the
user has.
Steve Langasek
postmodern programmer
Reply to: