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
Theo Chatzimichos posted on Fri, 25 Feb 2011 10:38:06 +0200 as excerpted:

> On Fri, Feb 25, 2011 at 10:17 AM, Andreas K. Huettel > <dilfridge@g.o> wrote: >> >> Dear all, >> >> at the last kde meeting we've been discussing the usefulness of the use >> flags consolekit and policykit. I'm quoting from the summary: >> >>> scarabeus and dilfridge are in favour of dropping them, since it >>> caused a lot of trouble debugging various user reports. reavertm >>> prefers adding it to IUSE defaults. No consensus was succeeded, the >>> topic will be continued in the gentoo-desktop mailing list. >> >> As an example, according to https://bugs.kde.org/show_bug.cgi?id=244444 >> policykit is _not_ a hard dependency of kde, but _required_ whenever >> you want to "run as" or configure something in systemsettings as root. >> >> The three options available are 1) removing the useflags, effectively >> "forcing them on". Easiest for us maintainers, >> 2) forcing them on with use.force in the profile, and trust that not so >> many users figure out how to get around this :) >> 3) making them "on by default" >> >> As a special gem, after switching one of the flags it may be necessary >> to recompile larger parts of kde and / or restart kdm. >> >> Opinions? > > The depedencies are indeed really small, but the reason that some of us > objected is that we want to follow upstream's decisions on what is > optional and what is not. A similar issue that emerged recently is > udisks and friends, which is also optional according to upstream and not > needed for people that want KDElibs for only a few apps and not for the > full DE. We'd like to have some user feedback on this before our final > decision.
This user's feedback, FWIW... I'd like some clarification on udisks dependencies. When I installed 4.6 (a couple days before it was unmasked to ~arch, I believe, so by definition still "raw", not complaining about that...)... I couldn't find any way to turn udisks off. Not that I'd want to, necessarily, but I was looking for the option. The bigger issue, however, was udisks pulling in lvm2, etc, as dependencies. Is that /really/ necessary? I had tried lvm2 on top of md- raid here some time back and decided it was too many layers to work with, debug, and worry about disaster recovery for, and unlike md-raid, which allows direct kernel auto-assembly of / and thus does NOT require an initramfs/initrd if root is built on it, lvm requires userspace assembly and thus an initramfs/initrd if root is on it, so lvm got kicked to the curb. Needless to say I was *NOT* particularly happy about having lvm2 show up in my dependency-merge lists again, especially when I tend to be very cautious with automounting and such things anyway, tending to keep them disabled (and I didn't enable dm in the kernel either, probably why kde 4.6's device-notifier appears to be broken, now, not that I really care, as I said, but just the case) But it seems if not for kdelibs or the basics, I'd still need udisks for k3b to work properly, and udisks at least /appears/ to require lvm2 (probably for the device-mapper userspace, which is bundled with it now). IOW, I don't so much worry about udisks itself, or udev, but is udisks' currently mandatory dependency on lvm2 /really/ necessary? Do even things like k3b's optical drive/disk sensing depend on lvm/device-mapper now? Or is there a way to make that work while omitting lvm2, even if it breaks automounting, etc, which I consider a security risk (especially after that security presentation that made linux/floss news recently) in any case, and really wouldn't mind doing without. If even MS is removing auto-play stuff now, for security reasons... isn't Linux going backward if we're replaying all the security mistakes MS is now leaving behind? As for consolekit and policykit, pretty much the same thing, but here, I'm primarily worried about security as the dependency tail didn't seem as bad. Personally I have an "admin" user that I can sudo to (with password) in a konsole, that in turn allows me from there passwordless sudo to anything. That works well. I know where the config for sudo is and how to change policies if I need to. Etc. I don't want or need the worry and additional security exposure of an entirely different mechanism, used to adjust system level settings also. I don't /want/ system level changes made or even possible via what remains to me kcontrol. So while others can enable those flags and use those bits if they want, I definitely want the ability to turn that off via USE flags retained. Since policykit is the way those are handled, that'd be the USE flag that needs retained. Consolekit similarly. It's additional complexity and area of security exposure that I don't particularly want or need on my system. -- 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