1 |
Samuli Suominen posted on Tue, 17 May 2011 03:20:40 +0300 as excerpted: |
2 |
|
3 |
> On 05/17/2011 03:15 AM, Samuli Suominen wrote: |
4 |
|
5 |
>> The above file would grant permission with or without active local |
6 |
>> ConsoleKit session to users in plugdev group to everything udisks |
7 |
>> handles. |
8 |
>> |
9 |
>> Notice that getting active ConsoleKit session you are now required to |
10 |
>> use PAM, or Display Manager like GDM with internal ConsoleKit support. |
11 |
>> |
12 |
>> Note that the PAM method requires you to have CONFIG_AUDITSYSCALL=y |
13 |
>> support enabled in kernel to get valid sessionid string and not all |
14 |
>> minor archs support this kernel option. |
15 |
|
16 |
User perspective... |
17 |
|
18 |
If it's at all possible to continue to have a consolekit/polkit-less |
19 |
system, making them USE-based dependencies of kde, gnome, etc, relying |
20 |
entirely on apparently now legacy groups, that should be done. Given |
21 |
upstream dependencies it might not be possible, or might require "dummy" |
22 |
libraries/services that simply return permitted for whatever and let |
23 |
kernel user and group permissions handle it, but having such dummy |
24 |
services is still a good thing, and /shouldn't/ be too hard to maintain, |
25 |
given most functionality would be stubbed in. |
26 |
|
27 |
I still remember the bad old days of the console pam module fighting with |
28 |
udev, etc, over permissions, and don't want to relive it. Having clear |
29 |
and simple group options that "just work" even when *kit is misconfigured |
30 |
or broken or not existing at all on a system is a valuable feature that |
31 |
IMO shouldn't be removed lightly. |
32 |
|
33 |
But "nice" doesn't mean it's actually available from upstreams, and I'm |
34 |
not in a position to maintain such a package, so... |
35 |
|
36 |
>> We could have similar .pkla files also for other stuff like bluetooth, |
37 |
>> networkmanager, shutdown/reboot, suspend and hibernate (upower), and |
38 |
>> the list continues. |
39 |
|
40 |
You mention having baselayout setup the groups, below. It's unclear, |
41 |
however, to which package these files should belong. Baselayout also |
42 |
(perhaps USE flag controlled)? The individual services? A separate |
43 |
package pulled in as a dependency where necessary? |
44 |
|
45 |
Note that as you describe these files, or at least as I envision them, |
46 |
they'd be much like logrotate files or the like -- they could be installed |
47 |
(to a non-active/sample location) by default, then copied/moved by the |
48 |
user to the appropriate location to activate. So baselayout or a separate |
49 |
package could install the whole batch and let the user activate-by-moving |
50 |
individual files into place as desired. |
51 |
|
52 |
>> The benefits are somewhat clear, things would work out of box for |
53 |
>> remote users beloging to right group, PAM-less users, as well as minor |
54 |
>> arches. |
55 |
>> |
56 |
>> The downside of this is that most users would propably end up using |
57 |
>> this as workaround for inactive ConsoleKit sessions that should really |
58 |
>> be local, but the user is just failing to configure his system in |
59 |
>> proper state to gain it (launching the X wrong way, wrong kernel opts, |
60 |
>> ...) |
61 |
>> |
62 |
>> And if we want this, should we stick to generalized plugdev group? |
63 |
>> |
64 |
>> Or perhaps group wheel for shutdown/reboot. Group storage for udisks. |
65 |
>> Group power for upower (hibernate, suspend). Group bluetooth for |
66 |
>> bluez. Group network for networkmanager? (Just throwing ideas...) |
67 |
>> |
68 |
>> So... any comments before I just pick what I think is best and commit |
69 |
>> the .pkla files (or not). I'm really 50-50 on this... |
70 |
|
71 |
I like the idea of separate groups. But I don't see a practical |
72 |
difference between allowing suspend/hibernate and shutdown/reboot, so that |
73 |
could be the same one. |
74 |
|
75 |
But preferably use power, not wheel. Just because I want my user to be |
76 |
able to suspend/hibernate/shutdown/reboot doesn't mean I want to give him |
77 |
the other privs (su...) associated with wheel. |
78 |
|
79 |
I do really like the idea of separating power from storage from network |
80 |
from bluez, tho. =:^) |
81 |
|
82 |
>> Would like to get this decided before p.masking HAL. |
83 |
|
84 |
HAL... the devil's spawn! How many, admins and devs alike, will be glad |
85 |
to see it be a fading memory like that console pam module?! |
86 |
|
87 |
> Futhermore I would like the baselayout package to create the groups |
88 |
> decided here, be it wheel (already there), plugdev, or more fine grained |
89 |
> storage/power ones. |
90 |
|
91 |
As above, the groups, but what about the files? |
92 |
|
93 |
> I think the "distribution policy" (be it the general consensus on this |
94 |
> thread) on this should be reflected in there. And it's the most |
95 |
> convinient place, then packages don't have to worry about creating |
96 |
> them... just follow |
97 |
|
98 |
No disagreement there. |
99 |
|
100 |
-- |
101 |
Duncan - List replies preferred. No HTML msgs. |
102 |
"Every nonfree program has a lord, a master -- |
103 |
and if you use the program, he is your master." Richard Stallman |