[Pkg-shadow-devel] Bug#478771: Bug#478771: passwd: shadow libraries ignore stale locks based only on PID

[xrgtn]

Hello,

14.05.08, 20:56, "Nicolas François" <nicolas.francois at centraliens.net>:
> On Wed, May 14, 2008 at 06:00:51PM +0400, xrgtn at yandex.ru wrote:
...
> > Maybe we should try combined 1/3 approach. 1st on flock-less
> > platforms, 3rd of flock-able ones.
>
> My idea was to let the admin remove the lock file herself.

OK, this is fine on systems which lack flock/lockf,
it's like manually performed option #1.

> If the system is restarted, or a locker process died for any reason, it
> might be better to warn the admin, and let her do the cleanup.

I agree, having automatic lock cleanup script to
be run on restart is probably not a very good idea,
the system administrator may want to implement this
himself, if/when the system is prone to occasional
reboots in midst of modifying passwd/shadow/group
files %) Sysadmin may know better, during which
boot stage this can be done best of all (before
NFS mount/after NFS mount/before "/tmp" cleanup
and so on).

> The user/group databases might be inconsistent, and only the admin may
> know what append, when, and what operation was ongoing.
> I don't know what is the error message currently, but it might be good to
> review it (them) to make sure it is helpful (at least to indicate that a
> lock file exists).
> It would however be too much to indicate that:
>  * another process might be using the database and she has to retry later
>  * one process might have die and left lock file. In that case, the user
>    must audit the system and then remove the lock file manually.

In fact, flock/lockf-produced lock on the file
wil be cleaned by the system (kernel) when
the holding process dies or closes the file.

That's why I consider flock/lockf locking as
one of the best resource protection methods
on unices. You can tell immediately and
reliably that the file is/isn't being hold
by another process.

There are still some problems, but IMO we
should implement flock/lockf for passwd.lock,
group.lock files.

>  * there might be a bug in a shadow tool or another tool that avoided the
>    lock file removal.

maybe SIGINT is not explicitly handled or
similar. But there's no way to cleanup after
itself on SIGKILL ;) (flock/lockf works here)

> But that could be mentioned in the manpages (FILES section).

Should be mentioned there too.

-- 
WBR,
xrgtn