On Mon, Aug 15, 2011 at 06:00:50PM +0100, Roger Leigh wrote: > On Mon, Aug 15, 2011 at 05:35:54PM +0100, Colin Watson wrote: > > On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote: > > > Are these any other downsides we need to consider? One issue is the > > > existence of badly broken programs³, which make stupid assumptions > > > about lockfiles. > > > > What about programs that need to write lock files which are already > > setgid something else? I don't have an example off the top of my head, > > but it would surprise me if there were none of these. > > IIRC Fedora have a setgid lock locking helper for this, which lockdev > uses internally. I'd need to check the details on a Fedora VM. IIRC > it checks if you have write perms on the device being locked, and so > individual programs don't need to be setgid lock unless they are not > using liblockdev. The use of an external helper means this is significantly slower than an open(…, O_CREAT) + flock(). While this works for some workloads, it doesn't for all. As my other question was: /var/lock (or /run/lock) was a good solution for transient, "cheap" locks for coordination between some cooperative programs. It would be ideal if we have a recipe for this after the permissions change. thanks, iustin
Attachment:
signature.asc
Description: Digital signature