On Sat, Aug 25, 2001 at 12:47:22AM -0400, Adam Slattery wrote: > On Sat, 25 Aug 2001, Solar Designer wrote: > > I suggest that you search the archives from a year ago when I've > > raised this question. > > Strange. These are the messages I was looking at. For some reason in my > mind I was thinking they were on the list. Everything seems to have > blured together from last week. > > There's an archive of the thread here if anybody is curious: > http://security-archive.merton.ox.ac.uk/security-audit-200008/index.html Most of the discussion was CC'd to both lists. > > > 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. > > It is quite possible to do proper inode-based (flock) locking with > rename(). It's been explained before, so I won't bother explaining it I'm not sure what exactly you refer to. Yes, it is possible to define inode-based locking conventions that will work for individual files, and it is even possible to define ones that will work for a group of files (such as for {passwd,shadow}, when adding/removing users), but it becomes tricky. You need to obtain a lock on the current passwd file, then before replacing you need to also obtain a lock on your new passwd file, then you need to keep fd for the original passwd file open until after you've also replaced the shadow file. This is needed because your rename(2) might happen between an open(2) and a flock/ fcntl in another process. Then there's the question of which file of a group you lock first. This has to be a part of the locking conventions, or deadlocks are possible. > here. Using such a scheme has the advantage (or disadvantage...) of only > locking the file that is needed rather than all files. It's so much simpler to define one way to lock the password files. Well, on Owl we will also have lckpwdf_tcb()/ulckpwdf_tcb() which work on individual tcb files, but those differ in that they don't require root privileges to lock own account record (no, we aren't making DoS attacks on others' ability to lock password files any easier by this change). > > Yes, there're other locking methods in use, see the discussion from a > > year ago. This is a bug. > > And it "still" hasn't be addressed. This is a distribution issue. It's unlikely that _all_ distribution vendors will treat this seriously. I mostly care about Owl. ;-) Well, the individual packages themselves could be changed to use consistent locking by default, but we don't see this happening either. > > lckpwdf(3) uses signals, too. And it's not sleep(3) but multiple > > password changes by different threads that I'm somewhat concerned > > about. > > This is one of the things I'm worried about too. I'll have to download > glibc source and see how they implemented lckpwdf. If it isn't > thread-safe, the module will then have to implement a locking scheme to > make sure only one thread has called lckpwdf(3) at a time. The glibc implementation does have the thread locks already. > How safe is lckpwdf() on other systems? Well, not all have it. Of those which do and I was able to find documentation for, only Solaris and HP-UX mention that their lckpwdf(3C) is thread-safe (perhaps starting with some versions). http://devresource.hp.com/devresource/Docs/Refs/SunPort/lall.html -- /sd
