Getting PAM and devfsd to work together smoothly has given me some
trouble. I think a line of advice in the devfs README would have
helped a lot:
In console.perms, handle not only /dev but also /dev-state.
Is this indeed how it's done? Comments much appreciated.
The problem: if you're using PAM to set device ownership, you're likely
to get bitten by the following scenario:
- When the user logs in after reboot, PAM sets permissions on devices.
- The console user tries to open a sound device, triggering a modprobe.
- Devfsd registers the sound device, but doesn't give ownership to the user.
- PAM does not get a chance to do its thing.
- Opening the sound device fails with permission denied.
- The user can work around this by logging in again, but that's ugly.
No solution:
- call PAM from within devfsd. PAM is not built to survive
the very first stages of booting; hanging machines can result.
The first solution:
- at login time, let PAM set the mode on some dummy file.
- on registration, for those devices where you want the PAM modes
to apply, let devfsd copy mode and ownership from the
dummy file to the new device. You'll need a bit of C code to copy
the modes reliably, without EXECUTE "sh -c 'ls | awk { blah } | sh'".
The second solution:
- use /dev-state in the normal manner.
- let PAM set modes not only in /dev, but also in /dev-state.
This is a trivial change in console.perms, and the devices for
PAM to manage in /dev-state are provided automatically by devfsd,
without any administrator intervention.
- now if devfsd is notified of a new device, it will apply the
modes that PAM thoughtfully supplied in /dev-state.
Comparing the two solutions:
- the first needs extra C code, and it requires PAM-sensitive
devices to be administered in both console.perms and devfsd.conf.
- the second solution works without extra C code, without extra
devfsd configuration, and handles everything in one place: console.perms.
Regards,
Erik
|