Mandatory vs. advisory file locking

[NickJohnson]

I'm trying to come up with a system of file locking that is adequate for my purposes, and I'm having trouble deciding on a few details.

The largest of these is whether to implement purely advisory locking, purely mandatory locking, or a mixture of both. For normal files, my system doesn't need any more out of the locking mechanism than any other, but there are some things that do need special treatment. Most importantly, windows are represented as files, and need to have some sort of mandatory exclusive write lock so that processes cannot write to each others' windows. A similar problem occurs with pipes (even unnamed ones, for complex reasons,) so I do need a mandatory write lock of some form.

However, I'm worried that if I implement a purely mandatory locking mechanism that there might be some performance problems, since (iirc) all reading processes would have to acquire shared locks. Is this actually an issue? And what if I implemented it so that exclusive locks are mandatory for writing, but shared locks are advisory for reading (but prevent exclusive locks)?

Also, how important is it to implement fine-grained locking (i.e. locks on regions instead of files)? Could I simply ignore it for now?

[Combuster]

There are several locking schemes: you can have exclusive locks, readlocks and writelocks, or some form of custom locks. File-based locking should not result in a penalty: you'd need to check for file existence, file permissions, and create the necessary structures for their management, plus you have to expect a bunch of read/write operations to follow. The amount of extra processing time should be small compared to actual I/O. Plus you only have to do actual lock logic upon opening the file. For writes (and maybe reads) you only need a simple if to check if the lock was granted when the file was opened - if you use memory-mapped files the hardware can do even that for you.

If you want to combine a form of advisory locking, you may want to consider the four locks: read-shared, read-exclusive, write-shared, write-exclusive. read-shared can always be acquired but does not guarantee the consistency of the file, nor does it grant write access. Write-shared obtains write rights without denying them for others, so you can have multiple processes writing the same file. WS can be acquired with existing WS and RS locks, RX can be acquired over RX and RS locks, WX can only be acquired if there's no WX/WS/RX lock present. You can implement all other forms of locking (including fine-grained ones) in software by just telling the system to use WS. Note that with any form of shared writing you need to consider possible atomicity requirements.

[NickJohnson]

The amount of extra processing time should be small compared to actual I/O.

Okay, maybe I was being paranoid.

You can implement all other forms of locking (including fine-grained ones) in software by just telling the system to use WS.

If multiple writers have WS locks, how does that allow them to implement fine-grained pseudo-WX locks? Wouldn't they have to communicate which regions they want to have exclusive write access to somehow?

[Gigasoft]

so that processes cannot write to each others' windows.

This sounds like a security policy. Processes shouldn't be interferimg with each others' windows because they have no business interfering with them at all, not because the windows are somehow busy at the time. Are you sure that it would be best implemented using synchronization locks?

[NickJohnson]

so that processes cannot write to each others' windows.

This sounds like a security policy. Processes shouldn't be interferimg with each others' windows because they have no business interfering with them at all, not because the windows are somehow busy at the time. Are you sure that it would be best implemented using synchronization locks?

My current security system only deals with user and group IDs, not process IDs, so it would be impossible to guarantee that a window is locked to a particular process. (Actually, it's not, but only because the window manager currently implements an additional permission layer so that it can do this.) It seems like mandatory exclusive write locks do effectively what I want anyway, so I might as well kill two birds with one stone instead of making security more complicated.

Plus, if I use locks instead, the controlling process of a window could in theory relinquish its WX lock if it wanted to transfer control to a different process. This probably wouldn't be too useful for most applications, but who knows?

[bluemoon]

If multiple writers have WS locks, how does that allow them to implement fine-grained pseudo-WX locks? Wouldn't they have to communicate which regions they want to have exclusive write access to somehow?

This is actually two questions:

1. To allow WX locks when there are WS writers, you have to block the WX until all WS unlocked. While WX is blocking subsequent WS lock will be queued.
2. To allow multiple locks on different region, you need to implement your own lock, with sometime like bitmap to test for yes-no instead of a single bit.
the lock function may look like this:

Code: Select all

wxlock ( int x, int y, int w, int h ); // x,y,w,h represent a rectangle to lock
OR
wxlock ( int start, int end );  // start-end represent a range to lock

And I agree with Gigasoft that there is limited case a process want to write to other process's window.
You don't want to have some application to lock your windows and intentionally forget to unlock it....

For screen-cast type application, they may just capture the whole screen buffer with a dedicated system api grab.

[Gigasoft]

My current security system only deals with user and group IDs, not process IDs, so it would be impossible to guarantee that a window is locked to a particular process.

But, is there any reason that windows need to have names and that one should be able to "open" existing windows at all? All a process needs is to be able to create a window, and have a handle to it in its handle table. If other processes need to open existing windows for any reason, perhaps it would be better to assign a set of granted access modes to each handle, so that opened window handles do not carry "write" access.

[NickJohnson]

My current security system only deals with user and group IDs, not process IDs, so it would be impossible to guarantee that a window is locked to a particular process.

But, is there any reason that windows need to have names and that one should be able to "open" existing windows at all? All a process needs is to be able to create a window, and have a handle to it in its handle table. If other processes need to open existing windows for any reason, perhaps it would be better to assign a set of granted access modes to each handle, so that opened window handles do not carry "write" access.

The issue is that my system does not have file descriptor tables/handle tables. File descriptors (known as "resource pointers" on my system) are valid (but do not imply access) regardless of which process they are in, and security is all done driver-side. This has a bunch of advantages for other things, but makes it so that every file is theoretically open-able even if it does not have a path in the VFS. So from a security standpoint, it is insufficient to make a file simply inaccessible from the VFS, and any policy that restricts access to a particular process must be implemented in the driver library (or the driver itself), which, since it needs to handle locking anyway, makes it sensible to use locking for this purpose.

1. To allow WX locks when there are WS writers, you have to block the WX until all WS unlocked. While WX is blocking subsequent WS lock will be queued.
2. To allow multiple locks on different region, you need to implement your own lock, with sometime like bitmap to test for yes-no instead of a single bit.
the lock function may look like this:

I know that that would work, but Combuster's response seemed to imply that it was possible to create a fine-grained advisory WX lock using only mandatory WS locks, and I was wondering if and how that would be done. I was probably misinterpreting it though.

[NickJohnson]

I'm also still wondering: are fine-grained locks that useful? Would it be a major disadvantage to not have fine-grained locks, for example in a server running a database? I've been searching around for some sort of data on this, but I can't find any. All I know is that most database software uses it (except sqlite, apparently.)