Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 438790 - kde-misc/polkit-kde-kcmodules: Store polkit configuration changes to /etc instead of /usr
Summary: kde-misc/polkit-kde-kcmodules: Store polkit configuration changes to /etc ins...
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] KDE (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo KDE team
URL:
Whiteboard: removed on 2013/12/30
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-18 12:34 UTC by Nikoli
Modified: 2013-12-30 10:16 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nikoli 2012-10-18 12:34:22 UTC
After editing polkit rules with kde systemsettings changes are saved only to '/usr/share/polkit-1/actions/*.policy', nothing is saved to /etc/ or /var/. But 
/usr/share/polkit-1/actions/ is not in $CONFIG_PROTECT, updating or reinstalling packages will destroy settings. Please fix.

Installed packages:
kde-base/systemsettings-4.8.5
kde-misc/polkit-kde-kcmodules-0.98_pre20120917
sys-auth/polkit-0.107-r1
sys-auth/polkit-kde-agent-0.99.0
sys-auth/polkit-qt-0.103.0
Comment 1 Samuli Suominen (RETIRED) gentoo-dev 2012-10-18 13:02:51 UTC
You shouldn't be editing anything in /usr directly but override the settings in /etc if needed. Namely JS based .rules files as described by 'man polkitd' in /etc/polkit-1/rules.d/

So no, we won't protect anything polkit/dbus/etc. related in /usr
Comment 2 Samuli Suominen (RETIRED) gentoo-dev 2012-10-18 13:04:51 UTC

*** This bug has been marked as a duplicate of bug 415583 ***
Comment 3 Nikoli 2012-10-18 13:25:51 UTC
I do not edit this files with text editor. I changed security settings with KDE tool and tool saved files in /usr instead of /etc. This is the main reason why kde herd is subscribed. systemsettings is not asking where to safe files.
Comment 4 Sergey Kondakov 2012-10-18 13:33:39 UTC
endeed, try telling that to KDE guys, Gentoo-devs.
they even store KDM settings under /usr (but you surely familiar with whole /usr/share/config). and what the hell users supposed to do about it ?
Comment 5 Samuli Suominen (RETIRED) gentoo-dev 2012-10-18 13:42:31 UTC
Then the configuration system from KDE is flawed and needs to be fixed to write proper JS .rules files to correct location, the /etc, as per polkit design
Comment 6 Samuli Suominen (RETIRED) gentoo-dev 2012-10-18 13:48:54 UTC
Note that /usr is designed so that it can be mounted as ro (read only) and polkit has always been designed to allow it, since the old "PolicyKit" times

If this needs upstream code (patch) then I'd suggest to not ship the faulty KCM module for now, or keep it strictly overlay based as non-supported
Comment 7 Sergey Kondakov 2012-10-18 14:00:41 UTC
indeed it's flawed (no data should be in /usr, which is changeable by users & processes over than package manager), but this is what we have: a major DE with this kind of design decision.
as a user, i hesitant to even bring it up to the upstream, as they don't take design criticism from "vocal minority" well.

therefore, i suggest something like making a more official pleading to them from willing Gentoo-devs about it.
Comment 8 Samuli Suominen (RETIRED) gentoo-dev 2012-10-18 14:16:46 UTC
Futhermore this explains why Gentoo users are struggling with polkit rules problems (many posts in forums and also open bugs in bugzilla) since editing the files in /usr makes the whole thing undebuggable mess

I'll need to make it a standard practise to close any polkit bugs with this KCM module installed as invalid :-/
Comment 9 Sergey Kondakov 2012-10-18 14:50:21 UTC
kde-misc/polkit-kde-kcmodules is a direct dependency of kde-base/kdelibs and, therefore, of whole KDE. this is how KDE officially deals with PolKit, as i gathered.
so, maybe ignoring that 'undebuggable mess' as a "standard practise" would be not such a good idea either. it will not go away by itself any time soon.
Comment 10 Michael Palimaka (kensington) gentoo-dev 2012-10-23 18:58:16 UTC
Not a regression, so does not block stabilisation.
Comment 11 Michael Palimaka (kensington) gentoo-dev 2012-10-24 06:01:38 UTC
The paths are hard-coded, so I am not really sure what we can do downstream.
Comment 12 Samuli Suominen (RETIRED) gentoo-dev 2012-10-24 06:07:04 UTC
(In reply to comment #11)
> The paths are hard-coded, so I am not really sure what we can do downstream.

Removing the package from gentoo-x86 would be a start. This is quite serious bug.
Comment 13 Samuli Suominen (RETIRED) gentoo-dev 2012-10-24 06:11:36 UTC
To emphatize this more:
The package is writing to *static files that should _never_ be edited in /usr beloging to other package*
Once removed from gentoo-x86, I'll add blockers on it in polkit ebuilds.
Comment 14 Sergey Kondakov 2012-10-24 11:39:07 UTC
(In reply to comment #11)
> The paths are hard-coded, so I am not really sure what we can do downstream.

as i said, you can communicate to the upstream, that this (putting/editing configs in /usr) is _not OK_.

(In reply to comment #12)
> (In reply to comment #11)
> > The paths are hard-coded, so I am not really sure what we can do downstream.
> 
> Removing the package from gentoo-x86 would be a start. This is quite serious
> bug.

are you going to remove entire KDE ? because this is what the core of it does, now it's just extends to a non-KDE configs (which _is_ insane, as insane as ripping polkit support entirely from it. are you even sure that KDE be fully-functional after that ?), you can't sweep it under the rug like that. this is not a accidental mistake, this is a design, it will not go away and make things nice and maintainable after a while by itself.

if you really want to do something useful by yourself and fast, i'd suggest like developing a patch, that makes it use proper paths.
Comment 15 Michael Palimaka (kensington) gentoo-dev 2012-10-24 11:42:06 UTC
(In reply to comment #14)
> as i said, you can communicate to the upstream, that this (putting/editing
> configs in /usr) is _not OK_.
Links to upstream bugreports welcome.

> if you really want to do something useful by yourself and fast, i'd suggest
> like developing a patch, that makes it use proper paths.
Patches also welcome.
Comment 16 Sergey Kondakov 2012-10-24 14:15:47 UTC
blocking and breaking a major DE instead of doing anything useful is not welcome, on the other hand.

personally, i'm done debating with either KDE-devs or you.
maybe you'll manage to painlessly remove kde-misc/polkit-kde-kcmodules from kdelibs's deps, maybe you'll not. but, hopefully, if anyone screws up my desktop too much, there're always alternatives. i just pity the ones, for whom that might come as a surprise on updating.
Comment 17 Chris Reffett (RETIRED) gentoo-dev Security 2012-10-24 15:32:27 UTC
Bug filed upstream, let the flame wars begin.
Comment 18 Chris Reffett (RETIRED) gentoo-dev Security 2012-10-31 16:50:11 UTC
Okay, quick summary of the upstream discussion:
1. Most places don't ship polkit-kde-kcmmodules (they're not officially recommended for general usage)
2. kdm has a similar deal with editing /usr settings, several distros (Fedora, Slackware) just symlink /usr/share/config/kdm to /etc/kde/kdm.
3. Debian patches to make /etc/kde4 the config directory for KDE.
4. Fedora also patches to make four settings for config locations: in ~, in /etc/ in /usr for fedora-shipped settings, and in /usr for upstream-shipped settings.
5. KDE Frameworks 5 will allow us to export XDG_CONFIG_DIRS for system-wide changes and XDG_CONFIG_HOME (defaulting to ~/.config), obviating the need for patches.

As things stand, I think it would be a bad idea to attempt to make these changes in the 4.9 timeframe, it's too soon. Kensington and I will look at implementing a fix when 4.10 is released, and I will bring this up at the next KDE team meeting so we can pick one of the options to implement.
Comment 19 Samuli Suominen (RETIRED) gentoo-dev 2012-10-31 17:09:33 UTC
I don't object adding

[ ... VERY quick snip of code ... ]

src_install() {
local envdfn=99polkit-kde
echo 'CONFIG_PROTECT_MASK="/usr/share/polkit-1/actions"' > "${T}"/${envdfn}
doenvd "${T}"/${envdfn}
}

[ ... end snip of code ]

to kde-misc/polkit-kde-kcmodules instead of the initial suggestion of adding it to polkit -- because the bug is not in polkit-1 and there is no reason why Xfce users, for example, should deal with stuff they shouldn't be dealing with

that's for meanwhile since upstream has now been contacted and there looks to be a plan according to Comment #18

(just saying with my polkit hat on that you can do that because KDE as a major desktop deserves an exception, even if it's bit off what is wanted. anyway you want, you have veto here too.)
Comment 20 Michael Palimaka (kensington) gentoo-dev 2012-11-01 15:25:21 UTC
Do we want to ship Samuli's suggestion in comment #19 with 4.9.3, or wait until 4.10 with a better fix?
Comment 21 Chris Reffett (RETIRED) gentoo-dev Security 2012-11-01 16:06:39 UTC
I am fine with adding that for now to sort these issues out fast, then we fix it right in 4.10.
Comment 22 Michael Palimaka (kensington) gentoo-dev 2012-11-05 14:51:33 UTC
(In reply to comment #19)
> src_install() {
> local envdfn=99polkit-kde
> echo 'CONFIG_PROTECT_MASK="/usr/share/polkit-1/actions"' > "${T}"/${envdfn}
> doenvd "${T}"/${envdfn}
> }

CONFIG_PROTECT or CONFIG_PROTECT_MASK?
Comment 23 Samuli Suominen (RETIRED) gentoo-dev 2012-11-17 11:01:08 UTC
(In reply to comment #22)
> (In reply to comment #19)
> > src_install() {
> > local envdfn=99polkit-kde
> > echo 'CONFIG_PROTECT_MASK="/usr/share/polkit-1/actions"' > "${T}"/${envdfn}
> > doenvd "${T}"/${envdfn}
> > }
> 
> CONFIG_PROTECT or CONFIG_PROTECT_MASK?

CONFIG_PROTECT, sorry that _MASK was a mistake (typo or brainfreeze :)
Comment 24 Chris Reffett (RETIRED) gentoo-dev Security 2012-11-18 06:56:49 UTC
I've revision-bumped the package and added the CONFIG_PROTECT bit, will request a stable on that soon since it's a fairly minor change. Kensington and I will start looking into the options we've seen for a permanent fix now that KDE 4.10 beta 1 is out, and experiment with it there.
Comment 25 Michael Palimaka (kensington) gentoo-dev 2013-03-26 13:03:09 UTC
S(In reply to comment #24)
> I've revision-bumped the package and added the CONFIG_PROTECT bit, will
> request a stable on that soon since it's a fairly minor change.
Stabilisation will occur along with KDE-4.10.1
Comment 26 Samuli Suominen (RETIRED) gentoo-dev 2013-03-26 14:39:49 UTC
I've been waiting for this to get lastrited... And now I see people talking of stabilizing it... Please :-(
Comment 27 Michael Palimaka (kensington) gentoo-dev 2013-03-26 16:06:30 UTC
(In reply to comment #26)
> I've been waiting for this to get lastrited... And now I see people talking
> of stabilizing it... Please :-(

The package was already stable, we are just stabilising a revision bump to stop the automatic overwriting. It is still a work-in-progress to get this fixed properly upstream.
Comment 28 Chris Reffett (RETIRED) gentoo-dev Security 2013-06-01 13:02:37 UTC
After discussion in the KDE team meeting, we've decided to remove the package rather than patch it. The dep on polkit-kde-kcmodules has been removed in 4.10.4 and all live versions in the KDE overlay. This leaves users with the package until it is depcleaned, but since the biggest problem has been with configuration files being overwritten on upgrade, I consider this acceptable. Once 4.10.4 or 4.10.5 is stablized, we will mask polkit-kde-kcmodules for lastrite and move it back to the KDE overlay, with the hope that eventually the upstream bug will be fixed and it might be suitable for inclusion in the tree again.
Comment 29 Johannes Huber gentoo-dev 2013-11-24 08:44:55 UTC
Removal announced on -dev and -dev-announce mailing lists.
Comment 30 Johannes Huber gentoo-dev 2013-12-30 10:16:50 UTC
Package removed from tree.