Other than a single device is opened next to make a user opens a plurality of devices in the process, but allows only one user to open the device. This solution makes it easy to test the device, because a user can read and write from several processes, but assume that the user is responsible for maintaining data integrity in a number of access this is achieved by adding a check in the open method; such checks are usually carried out after the license check, and can only make access more restrictive than is owned by person and group permission bits specified limit. this is ttys and access strategy used is the same, but it does not depend on external privileged program.
These access strategy to implement the policy to open some strange than the single in this case, two: an open count and the uid equipment owners once again, the best place for this is in terms of equipment structure; we examples of the use of global variables in place, because of the reasons previously explained the scullsingle. sculluid devices is that name.
open call agree that when you first open the access but remember the device owner. This means that a user can open the device multiple times, thus allowing multiple processes to coordinate concurrent operation of the equipment. At the same time, no other users can open it , thus avoiding external interference because this version of the function almost the same before, so the relevant section is copied here:
spin_lock(&scull_u_lock); if (scull_u_count &&
(scull_u_owner != current->uid) && /* allow user */ (scull_u_owner != current->euid) && /* allow whoever did su */
!capable(CAP_DAC_OVERRIDE))
{ /* still allow root */
spin_unlock(&scull_u_lock);
return -EBUSY; /* -EPERM would confuse the user */
}
if (scull_u_count == 0)
scull_u_owner = current->uid; /* grab it */
scull_u_count++; spin_unlock(&scull_u_lock);
Note sculluid If there are two variables (scull_u_owner and scull_u_count) to control access to the device, and thus a plurality of processes may be concurrently accessed. In order to secure these variables, we use a spin lock controlling access to their (scull_u_lock). Without this lock, two (or more) processes can be tested scull_u_count the same time, and are likely to think that they have ownership of the equipment. here the use of a spin lock because the lock is held very short time and driving do not do things any sleep while holding the lock.
We chose instead to return -EBUSY -EPERM, even if the code is detected during the license in order to give a user is denied access in the right direction. For the "permission denied" response is often the mode checking / dev file and owner and "device busy" correctly recommends that users should look for a process already in use of the device.
This code also checks to see whether're trying to open the process has the ability to overwrite the file access permissions; if so, open the owner is allowed even if the process is not open device CAP_DAC_OVERRIDE capacity for the task in this case.
release method looks like the following:
static int scull_u_release(struct inode *inode, struct file *filp)
{
spin_lock(&scull_u_lock); scull_u_count--; /* nothing else */ spin_unlock(&scull_u_lock);
return 0;
}
Again, we must acquire the lock before modifying it count, to ensure that we do not have another process and competition.