On Fri, Aug 24, 2001 at 06:38:17PM -0400, Adam Slattery wrote: > This was briefly discussed last week, but no conclusion was reached. I suggest that you search the archives from a year ago when I've raised this question. > How should modules lock files? In ways compatible with locking conventions for the particular files on the particular OS. > flock(2) - not 100% reliable on some filesystems, but pretty good. > > fcntl(2) - looks good. Applying file locking to the files themselves is wrong for at least password files as those are to be replaced with a rename(2). There should be a separate lock file which you apply an advisory lock to. > lckpwdf(3) - undocumented, does it protect /etc/shadow? The convention is that it's used to protect both passwd and shadow files. It doesn't (and shouldn't) touch the files themselves, for the reason I've just explained. On Owl, it may also protect our /etc/tcb directory tree (but there will be alternate locking calls in libtcb that don't require root privileges to lock own tcb entry). There're certain signal races with existing implementations I've seen. > lckpwdf(pam_unix) - would be pam specific, ties up SIGALRM > > others? Yes, there're other locking methods in use, see the discussion from a year ago. This is a bug. > Perhaps a combination of these things is needed to at least attempt to > maintain compatibility with other software, No, all software needs to be fixed to use one locking method, and lckpwdf(3) seems to be the best choice (the signal races need to be fixed, but are just an implementation issue). > but then again these functions may be mutually exclusive on some systems. Exactly. Plus if you use more than one locking method the order of calls matters or you may get a deadlock. > For now I'm just using pam_unix's method of falling back on it's own code > if the system doesn't have lckpwdf(3). However, this reserves SIGALRM in > threaded applications that make use of PAM, which means they shouldn't > (read: can't) use sleep(3). lckpwdf(3) uses signals, too. And it's not sleep(3) but multiple password changes by different threads that I'm somewhat concerned about. > We should come up with a good solutions and document it in the module > writers guide. I personally don't have any brilliant proposals, nor will > I ever since I don't do any coding on some of the systems Linux-PAM runs > on (Ultrix, AIX, HP-UX, OSX, ...) I'm not sure it's a good idea to install the Linux-PAM-provided pam_unix on all systems that are to some extent supported by Linux-PAM. Native password file locking conventions are very different on different systems. > The next problem is read locking vs write locking. To read such files is > it neccisary to call lckpwdf (if that's what we use). You would have to > because it's the only way to prevent another process/thread from writing > to your file. An fcntl() or flock() solution would solve this, but that > may be impossible depending on compatibility concerns. There's no locking needed to read password files. They're to be replaced atomically. I don't know of a system which defines things differently, as that would require privileges to do any getpw*(3) calls. -- /sd
