Re: wtmp locking problem
kai@khms.westfalen.de (Kai Henningsen) writes:
> The denial of service attack, obviously, is that locking whatever the lock
> file is prevents people from logging in.
Well, duh.
> How the other lockfile helps prevent this is, however, unclear to me - if
> it works by removing rights to the file, those could just as well be
> removed from *tmp, IMHO.
Actually it does, and no they can't. It's actually very simple. I
stupidly forgot about the non-ideal choice of disallowing fcntl() and
flock() locks on the same file. A process can place an advisory fcntl
style lock on the file if it has read permssion, and then login can't
flock the file. You need write permission to flock a file.
The whole issue with locking wtmp and utmp sounds bogus to me. wtmp
is only appended to, which is guaranteed atomic, and only the
appropriate entry in utmp is updated, so why are locks even needed?
So I may have been totally off-base here, and the corruption is
something entirely different.
The shadow login doesn't (correctly, imo) place a lock on wtmp, so the
whole issue will soon be moot.
Guy
Reply to: