Red Hat Bugzilla – Bug 202132
pam update breaks dvb permissions
Last modified: 2007-11-30 17:11:40 EST
After upgrading to pam 0.99.5.0-5.fc5, the permissions of the DVB device nodes
of my headless VDR-based PVR box are hosed.
The new dvb stuff in /etc/security/console.perms.d/50-default.perms is the
culprit. First of all, the defaults for dvb devices are off sync with udev
(0660 in udev, 0600 in pam).
But an even worse issue is that it no longer matters what I set in udev's config
for the modes or group (I need 0660, root:video), pam goes and overwrites that
at boot even when nobody has ever logged in.
I can of course configure it in both pam and udev, but that sucks. Any other ideas?
I could change pam to have 0660 to keep in sync with udev however it wouldn't
change the situation much for you because it would be reset to the root group
anyway. But you of course don't have to configure it in both pam and udev - it
should be fine to configure it in pam only.
Yep, I figured that doing it in pam is enough afterwards but forgot to note it
here. <console> 0660 <dvb> 0660 <root> would be an improvement even if it
wouldn't directly help me out in this scenario. I suppose there are other
things besides dvb that should receive the same sync operation between udev and
pam, /dev/ircomm* is one obvious example.
But I think it would be better to try to get the disconnect between udev and
pam_console fixed For Real(tm) some way. I don't have good suggestions how to
do that right now, but here's one slightly related suggestion:
Make it possible to leave the user/group alone when pam_console sets ownerships,
ditto some bits of the mode. For example:
<console> 06** <dvb> 06** root.*
...could leave the things marked with asterisks (group and the two last digits
of the mode) untouched when changing permissions etc.
The problem is with the reset permissions and ownership - you cannot leave
things as they are because malicious console user could set group ownership or
mode to different values than they were set by root (udev).
I think that an improvement would be to add appropriate groups for various
devices to a default config of udev and pam_console + /etc/group.
A real solution would be to use ACLs for the device nodes so there could be for
example multiple console owners and so on.
Hmm, I have a strange deja vu feeling that someone (maybe you?) has pointed out
that problem to me before. Thanks for the reminder. However, that problem
already kind of exists: a malicious console user can change groups or modes at
will while logged in anyway, no?
In case additional groups are under consideration, let me pimp adding "video":
it is a standard/shipped one in at least SuSE, Mandriva, Debian, and Ubuntu. In
addition to those, udev rules files shipped with upstream udev suggest that it
is also available in Gentoo, Frugalware and Slackware. And in addition to udev,
I know some other projects whose upstream documentation assumes that it is
available out of the box.
He can change them, but he cannot elevate his privileges this way only make it
inaccessible to other people. But if the permissions and group were not reset
after he logs out he could get access to the devices even when he is no longer
the console user.
Ok. By the way, I'll probably need to do the video group config in both udev
and console.perms after all, this scenario is in a package (VDR, under review
for Extras in #190343) which needs access to DVB devices even if the local admin
chooses to disable access to them for console users.
Wontfix for now - we would have to obtain a new system group for video devices
for this to work. And the device management will be substantially changed in
near future with the PolicyKit etc.