1 |
Theo Chatzimichos posted on Fri, 25 Feb 2011 10:38:06 +0200 as excerpted: |
2 |
|
3 |
> On Fri, Feb 25, 2011 at 10:17 AM, Andreas K. Huettel |
4 |
> <dilfridge@g.o> wrote: |
5 |
>> |
6 |
>> Dear all, |
7 |
>> |
8 |
>> at the last kde meeting we've been discussing the usefulness of the use |
9 |
>> flags consolekit and policykit. I'm quoting from the summary: |
10 |
>> |
11 |
>>> scarabeus and dilfridge are in favour of dropping them, since it |
12 |
>>> caused a lot of trouble debugging various user reports. reavertm |
13 |
>>> prefers adding it to IUSE defaults. No consensus was succeeded, the |
14 |
>>> topic will be continued in the gentoo-desktop mailing list. |
15 |
>> |
16 |
>> As an example, according to https://bugs.kde.org/show_bug.cgi?id=244444 |
17 |
>> policykit is _not_ a hard dependency of kde, but _required_ whenever |
18 |
>> you want to "run as" or configure something in systemsettings as root. |
19 |
>> |
20 |
>> The three options available are 1) removing the useflags, effectively |
21 |
>> "forcing them on". Easiest for us maintainers, |
22 |
>> 2) forcing them on with use.force in the profile, and trust that not so |
23 |
>> many users figure out how to get around this :) |
24 |
>> 3) making them "on by default" |
25 |
>> |
26 |
>> As a special gem, after switching one of the flags it may be necessary |
27 |
>> to recompile larger parts of kde and / or restart kdm. |
28 |
>> |
29 |
>> Opinions? |
30 |
> |
31 |
> The depedencies are indeed really small, but the reason that some of us |
32 |
> objected is that we want to follow upstream's decisions on what is |
33 |
> optional and what is not. A similar issue that emerged recently is |
34 |
> udisks and friends, which is also optional according to upstream and not |
35 |
> needed for people that want KDElibs for only a few apps and not for the |
36 |
> full DE. We'd like to have some user feedback on this before our final |
37 |
> decision. |
38 |
|
39 |
This user's feedback, FWIW... |
40 |
|
41 |
I'd like some clarification on udisks dependencies. When I installed 4.6 |
42 |
(a couple days before it was unmasked to ~arch, I believe, so by |
43 |
definition still "raw", not complaining about that...)... I couldn't find |
44 |
any way to turn udisks off. Not that I'd want to, necessarily, but I was |
45 |
looking for the option. |
46 |
|
47 |
The bigger issue, however, was udisks pulling in lvm2, etc, as |
48 |
dependencies. Is that /really/ necessary? I had tried lvm2 on top of md- |
49 |
raid here some time back and decided it was too many layers to work with, |
50 |
debug, and worry about disaster recovery for, and unlike md-raid, which |
51 |
allows direct kernel auto-assembly of / and thus does NOT require an |
52 |
initramfs/initrd if root is built on it, lvm requires userspace assembly |
53 |
and thus an initramfs/initrd if root is on it, so lvm got kicked to the |
54 |
curb. |
55 |
|
56 |
Needless to say I was *NOT* particularly happy about having lvm2 show up |
57 |
in my dependency-merge lists again, especially when I tend to be very |
58 |
cautious with automounting and such things anyway, tending to keep them |
59 |
disabled (and I didn't enable dm in the kernel either, probably why kde |
60 |
4.6's device-notifier appears to be broken, now, not that I really care, |
61 |
as I said, but just the case) |
62 |
|
63 |
But it seems if not for kdelibs or the basics, I'd still need udisks for |
64 |
k3b to work properly, and udisks at least /appears/ to require lvm2 |
65 |
(probably for the device-mapper userspace, which is bundled with it now). |
66 |
|
67 |
IOW, I don't so much worry about udisks itself, or udev, but is udisks' |
68 |
currently mandatory dependency on lvm2 /really/ necessary? Do even things |
69 |
like k3b's optical drive/disk sensing depend on lvm/device-mapper now? Or |
70 |
is there a way to make that work while omitting lvm2, even if it breaks |
71 |
automounting, etc, which I consider a security risk (especially after that |
72 |
security presentation that made linux/floss news recently) in any case, |
73 |
and really wouldn't mind doing without. If even MS is removing auto-play |
74 |
stuff now, for security reasons... isn't Linux going backward if we're |
75 |
replaying all the security mistakes MS is now leaving behind? |
76 |
|
77 |
|
78 |
As for consolekit and policykit, pretty much the same thing, but here, I'm |
79 |
primarily worried about security as the dependency tail didn't seem as |
80 |
bad. Personally I have an "admin" user that I can sudo to (with password) |
81 |
in a konsole, that in turn allows me from there passwordless sudo to |
82 |
anything. That works well. I know where the config for sudo is and how |
83 |
to change policies if I need to. Etc. I don't want or need the worry and |
84 |
additional security exposure of an entirely different mechanism, used to |
85 |
adjust system level settings also. |
86 |
|
87 |
I don't /want/ system level changes made or even possible via what remains |
88 |
to me kcontrol. So while others can enable those flags and use those bits |
89 |
if they want, I definitely want the ability to turn that off via USE flags |
90 |
retained. |
91 |
|
92 |
Since policykit is the way those are handled, that'd be the USE flag that |
93 |
needs retained. Consolekit similarly. It's additional complexity and |
94 |
area of security exposure that I don't particularly want or need on my |
95 |
system. |
96 |
|
97 |
-- |
98 |
Duncan - List replies preferred. No HTML msgs. |
99 |
"Every nonfree program has a lord, a master -- |
100 |
and if you use the program, he is your master." Richard Stallman |