Gentoo Archives: gentoo-desktop

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-desktop@l.g.o
Subject: [gentoo-desktop] Re: use flags consolekit and policykit
Date: Fri, 25 Feb 2011 11:08:18
Message-Id: pan.2011.02.25.11.06.19@cox.net
In Reply to: Re: [gentoo-desktop] use flags consolekit and policykit by Theo Chatzimichos
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