Re: [Bug, 2.1.3] getlogin() can call alarm() but shouldn't.

[James Antill <james at and dot org>]

Mark Kettenis <kettenis@wins.uva.nl> writes:

> Ouch, I knew this was going to bite me sooner or later.
> 
> The problem is that we need to do locking on the user accounting
> database to make sure that two programs are prevented from modifying
> its contents at the same time.  However, since every user can hold a
> read lock on it, we need to beak the lock after a certain amount of
> time if we cannot get it to prevent all sorts of denial of service
> attacks (i.e. by holding a read lock a malicious user could prevent
> other people from logging in to the system).  There is no other way to
> interrupt the a program blocking in fcntl (..., F_SETLKW, ...), other
> than by a signal, and I believe SIGALRM is the only option.
>
> I'd love to see a different solution to this problem, but I haven't
> found one.  Unfortunately the POSIX realtime extensions aren't
> implemented yet on Linux.

 But unless I'm missing something the alarm() calls in
sysdeps/generic/utmp_file.c don't fix the problem.
 If you are just worrid about the call just after the alarm, as the
code implies, then you can use SETLK (the non-blocking version of
SETLKW) in a sleeping loop. If you are worrid about _other_
programs, as the above implies, then you can't do anything about it
anyway (and the alarm() call won't help you).

-- 
James Antill -- james@and.org
"If we can't keep this sort of thing out of the kernel, we might as well
pack it up and go run Solaris." -- Larry McVoy,
                                    Talking about adding DSM into Linux.