Access Control on a Device File
Offering access control is sometimes vital for the reliability of a device node. Not only should unauthorized users not be permitted to use the device (which is enforced by the filesystem permission bits), but sometimes only one authorized user should be allowed to open the device at a time.
None of the code shown up to now implements any access control in addition to the filesystem permission bits. If the open system call forwards the request to the driver, open will succeed. I’m now going to introduce a few techniques for implementing some additional checks.
The problem is similar to that of using ttys. In that case, the login process changes the ownership of the device node whenever a user logs into the system, in order to prevent intrusion in the tty data flow. However, it’s impractical to use a privileged program to change the ownership of a device every time it is opened, just to grant unique access to it.
Every device shown in this section has the same behavior as the bare scull device (that is, it implements a persistent memory area); it differs from scull only in access control, which is implemented in the open and close operations.
Single-Open Devices
The brute-force way to provide access control is to permit a device to be opened by only one process at a time (single-openness). I personally dislike this technique, because it inhibits user ingenuity. A user might well want to run different processes on the same device, one reading status ...
Get Linux Device Drivers now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.