Samuli Suominen posted on Tue, 17 May 2011 03:20:40 +0300 as excerpted: > On 05/17/2011 03:15 AM, Samuli Suominen wrote:
>> The above file would grant permission with or without active local >> ConsoleKit session to users in plugdev group to everything udisks >> handles. >> >> Notice that getting active ConsoleKit session you are now required to >> use PAM, or Display Manager like GDM with internal ConsoleKit support. >> >> Note that the PAM method requires you to have CONFIG_AUDITSYSCALL=y >> support enabled in kernel to get valid sessionid string and not all >> minor archs support this kernel option. User perspective... If it's at all possible to continue to have a consolekit/polkit-less system, making them USE-based dependencies of kde, gnome, etc, relying entirely on apparently now legacy groups, that should be done. Given upstream dependencies it might not be possible, or might require "dummy" libraries/services that simply return permitted for whatever and let kernel user and group permissions handle it, but having such dummy services is still a good thing, and /shouldn't/ be too hard to maintain, given most functionality would be stubbed in. I still remember the bad old days of the console pam module fighting with udev, etc, over permissions, and don't want to relive it. Having clear and simple group options that "just work" even when *kit is misconfigured or broken or not existing at all on a system is a valuable feature that IMO shouldn't be removed lightly. But "nice" doesn't mean it's actually available from upstreams, and I'm not in a position to maintain such a package, so... >> We could have similar .pkla files also for other stuff like bluetooth, >> networkmanager, shutdown/reboot, suspend and hibernate (upower), and >> the list continues. You mention having baselayout setup the groups, below. It's unclear, however, to which package these files should belong. Baselayout also (perhaps USE flag controlled)? The individual services? A separate package pulled in as a dependency where necessary? Note that as you describe these files, or at least as I envision them, they'd be much like logrotate files or the like -- they could be installed (to a non-active/sample location) by default, then copied/moved by the user to the appropriate location to activate. So baselayout or a separate package could install the whole batch and let the user activate-by-moving individual files into place as desired. >> The benefits are somewhat clear, things would work out of box for >> remote users beloging to right group, PAM-less users, as well as minor >> arches. >> >> The downside of this is that most users would propably end up using >> this as workaround for inactive ConsoleKit sessions that should really >> be local, but the user is just failing to configure his system in >> proper state to gain it (launching the X wrong way, wrong kernel opts, >> ...) >> >> And if we want this, should we stick to generalized plugdev group? >> >> Or perhaps group wheel for shutdown/reboot. Group storage for udisks. >> Group power for upower (hibernate, suspend). Group bluetooth for >> bluez. Group network for networkmanager? (Just throwing ideas...) >> >> So... any comments before I just pick what I think is best and commit >> the .pkla files (or not). I'm really 50-50 on this... I like the idea of separate groups. But I don't see a practical difference between allowing suspend/hibernate and shutdown/reboot, so that could be the same one. But preferably use power, not wheel. Just because I want my user to be able to suspend/hibernate/shutdown/reboot doesn't mean I want to give him the other privs (su...) associated with wheel. I do really like the idea of separating power from storage from network from bluez, tho. =:^) >> Would like to get this decided before p.masking HAL. HAL... the devil's spawn! How many, admins and devs alike, will be glad to see it be a fading memory like that console pam module?! > Futhermore I would like the baselayout package to create the groups > decided here, be it wheel (already there), plugdev, or more fine grained > storage/power ones. As above, the groups, but what about the files? > I think the "distribution policy" (be it the general consensus on this > thread) on this should be reflected in there. And it's the most > convinient place, then packages don't have to worry about creating > them... just follow No disagreement there. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
