[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-desktop
Subject:    [gentoo-desktop] Re: use flags consolekit and policykit
From:       Duncan <1i5t5.duncan () cox ! net>
Date:       2011-02-25 11:06:20
Message-ID: pan.2011.02.25.11.06.19 () cox ! net
[Download RAW message or body]

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@gentoo.org> 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


[prev in list] [next in list] [prev in thread] [next in thread]