(sorry for the delay in my response)
Solar Designer <solar@false.com> wrote:
> > > Only #1 and #4 use compatible locking.
>
> I failed to notice that shadow-utils uses two kinds of locking at
> the same time, one of which is compatible with pam_unix. util-linux
> remains a problem. Also, you can't use both pwdb and pam_unix on a
> system.
I highly recommend using lckpwdf(), which has been available for
quite a long time now (also in libc 5.4.x if I remember correctly).
The other kind of locking in the shadow suite is kept mainly for
historical reasons, and because lckpwdf() is currently only used
for password files and not for group files.
Are there any programs outside the shadow suite which need to modify
group files directly, not using group{add,mod,del}? If yes, it is
probably OK to say that lckpwdf() should be used to protect group
files as well, and change the code to do this; but group files are
rarely modified compared to password files.
> I'm using #4 for my PAM'ified systems now. Still need to "port" some
> of the reliability fixes I did for libpwdb to the password file I/O
> routines found in shadow-utils.
Just curious, what are these fixes? These routines were meant to be
quite reliable, though I have received one bug report recently: very
long lines (>8K characters) in group files are truncated (this is a
very old bug, but reported after shadow-20000826 was released, so I'll
probably make another bugfix release soon, probably the last one from
me after all these years...).
> BTW, I still don't know why Red Hat prefers the util-linux versions.
> The PAM support in chsh and chfn of shadow-utils seems to work fine
> so far. vipw and vigr from shadow-utils also support editing of the
> shadow files, which the util-linux versions don't.
Probably chfn and chsh in the shadow suite didn't have PAM support
(didn't even authenticate the user) at the time when Red Hat made
the decision to use the util-linux versions. Fortunately, this feature
was fairly easy to add (the hardest part of adding PAM support was to
add it to login, but now it is there and ships with Debian 2.2, thanks
to the hard work of Ben Collins <bcollins@debian.org>).
> > Ok, looked to source. It seemed to be the best is to use
> > system-supplied locking mechanism in all cases. One routine
>
> Agreed.
>
> > that can be used is lckpwdf (and ulckpwdf to unlock) if it
> > exists. I don't know where it comes from: in glibc, there is
> > no documentation on it; on Solaris 2.6, man lckpwdf gives:
> > NOTES
> > These routines are for internal use only; compatibility
> > is not guaranteed.
>
> Still, glibc provides a lckpwdf in <shadow.h>, and the implementation
> looks fine. A man page would be nice.
Yes (again), use lckpwdf(). While undocumented, the interface is
the same as the Solaris one, and it probably hasn't changed for the
past 10 years or so...
> > Well, I see two common locking mechanisms:
> >
> > lckpwdf way is creating /etc/.pwd.lock file to lock
> > both passwd and shadow
>
> It is important that .pwd.lock is also fcntl()-locked, which allows
> for stale lock files to be overridden with no extra checks.
Yes, and it is also important to not remove /etc/.pwd.lock (some
"adduser" scripts in some distributions did this). Otherwise you
have a race and two processes can get write access at the same time.
> > I looked to lckpwdf implementation in glibc -- it is
> > pretty cheap (it does not checks for stale lock, but
> > this is rather ok for this sort of things I think).
>
> It does the fcntl, and that's enough, -- no explicit checks needed.
Yes. It is pretty cheap (in the sense of "efficient", contrary to
"expensive") because (after /etc/.pwd.lock is initially created)
it doesn't need to create/delete files, yet has no problems with
stale locks. fcntl() locks might even sometimes work over (decent
implementations of) NFS if you are lucky :-).
Regards,
Marek
