Several parts of the utopia project need pam_console. In its current state however, pam_console (with its munging of /dev/* perms) is undesireable. Here are my thoughts... remove /etc/security/console.perms from the default pam_console install tweak/remove /etc/security/console.apps from the default pam_console install remove the pam_console USE flag and install by default There may be things I'm not aware of... What are your thoughts?
I have to disagree here. pam_console is a very Fedora/Redhat specific thing as far as HAL (which is basically the Utopia project) you'd like to use this for. I quote, David Zeuthen, upstream HAL main man in his outline for HAL 0.5.x, which is what you're posting this bug for. "Basically, to determine if the calling process (identified by uid and pid) invoking a D-BUS method is authorized to do so. This is not a so big deal today, but for planned high-level operations such as Eject() on the org.freedesktop.Hal.Device.Block interface or Setup() on the org.freedesktop.Hal.Device.Block.Crypto (see my mail on encrypted storage), I imagine distributions are interested in not letting every random user invoke these. There are other examples of methods it makes sense to expose. Ideally, such policy should be expressed in D-BUS but no-one have did this in a distribution independent fashion yet [1]. For Fedora, I will probably initially use pam_console to only let authorized users at the console perform such operations. It would make sense to have a standard auth system to express e.g. that only /usr/bin/nautilus invoked by an authorized console user may invoke method Foo() on interface Bar. I'm not planning to spend a lot of time on this though; the implementation for Fedora will just be using pam_console. Stuff like that, basically. [1] : There is the at_console policy piece in D-BUS but that is pam_console/Red Hat specific - not very nice." As you can tell, upstream even sees that there needs to be a better solution. I think it's up to us to come up with this other solution. As a member of Gentopia group, I disagree with this one. I'm CCing the rest of the Gentopia group. genstef also disagrees with this plan of action.
We all agree there needs to be a better solution! However, there isn't one right now. Which is why I'd like to remove the offensive bits of pam_console. We really need the "depend on package x with use flag y" feature here. In any case the 0.5.2 hal ebuild in the overlay now has the pam_console use flag, so this is entirely optional. HOWEVER, HAL/DBUS need some reliable way to determine if the user is logging in remotely or locally. I'd still like to remove the /etc/security stuff from pam_console so that it would be less offensive to use. The other option may be to split pam_console into a separate package.
We used pam_console historically because we did not have udev, and I guess we should have done a better job of devfs.conf. It however is a pita to maintain with the devfs support (which I'm going to punt in pam-0.79), and due to its glib dependency a pita to have without /usr/lib* dependencies (check pam-0.78-r2 to see the amount of effort). Also some reports have it as racey ... In general I would have liked to drop it totally in pam-0.79 (and are going to try), so I would rather that you guys do a 'out of pam ebuild' if you really want to have this headace.
I have an idea about this, but requires a bit of user configuration. I'll try to get a look at that tomorrow, if I remember, if not, someone that is interested in this please ping me in irc and I'll remember :)
Some additional info is that by default pam_console installation is blocking proper mounting of cdrom and maybe other devices, because it is too restrictive on those devices by default (0600), that way making hal daemon unable to access the device after logging in in GDM to gnome for example. At least the ebuild of hal should contain some info about this situation so that users can edit their /etc/security to make it usable for cdrom etc. ... I spent 1 day of useless emerging to find out that this was ther problem.
Linux-PAM 0.99 won't have pam_console at all (I'm not going to apply the same load of patches from RedHat this time), so pam_console will need an ebuild of its own. This should solve most of the problems already.
