Ask your questions here.
Post a reply

Well I broke pkexec somehow, synaptic opens without a passwd

Thu Sep 22, 2016 5:48 pm

Don't know where along the line it happened, but something I did whilst chopping out cruft, caused an issue, synaptic now opens with a click without asking for the root password, and so does Gparted as it now apparently uses pkexec too.

Never understood why they use pkexec instead of gksu, but I never broke it before so I didn't mess with it.

I can make another menu entry easy enough and use "gksu synaptic" and it works fine, but going forward with rolling these little test iso's i'm concerned that if an update to synaptic gets pushed from upstream, that it will wipe out any new .desktop and menu entry I make and revert to pkexec.

I read the man page and other docs about it last night, and they gave a whole lotta complex reasons for using it, a lot of them repeatedly mentioned "security", but doesn't seem all that secure to me if can get broken that easy and the default behavior when that happens is to allow a user to open synaptic or gparted as root without having to have a password.

Any ideas or enlightenment would be greatly appreciated, I have one more run to do on my 32 bit and it's done (hopefully, if I don't break anything else) and I started on a 64 bit version yesterday too, but can't go any further until I figure this out.

I'm off to search for answers, but thought i'd post here first as y'all have a lot of experience with Devuan already that I don't.

Thanks!
~greenjeans

Re: Well I broke pkexec somehow, synaptic opens without a pa

Thu Sep 22, 2016 6:04 pm

I still use gksu. It just works. :)

Re: Well I broke pkexec somehow, synaptic opens without a pa

Thu Sep 22, 2016 6:28 pm

I don't use gui-apps via gksu or similar stuff, as i don't use a display-manager (i just become root in a terminal and start them).
Anyway there once was an incident, that one enters his root password once, in a pop-up window, and can have "remember root password" enabled.
You might wanna have a look at that "problem".

well: purge pkexec ...

Re: Well I broke pkexec somehow, synaptic opens without a pa

Thu Sep 22, 2016 6:32 pm

golinux wrote:I still use gksu. It just works. :)


I know right? That was my first instinct, to just delete the current .desktop entries for synaptic in usr/share/applications, and make a new one that uses gksu. And I haven't ever seen that many updates for synaptic come down the pike in the course of normal use over time.

But as they say, nature always sides with the hidden flaw, and Murphy's law being what it is, somebody will install some system I made, an update gets pushed and Synaptic or even worse Gparted once again will open with just a click with no password required, and somebody's kid will be playing on mom or dads computer and start pushing buttons, find Gparted and think "oh cool, what happens if I do this?", and carnage will ensue... :cry:

Re: Well I broke pkexec somehow, synaptic opens without a pa

Thu Sep 22, 2016 6:38 pm

nadir wrote:Anyway there once was an incident, that one enters his root password once, in a pop-up window, and can have "remember root password" enabled.
You might wanna have a look at that "problem".



That makes sense, have had issues exactly like that in the past with other stuff, thanks, that helps point me where to dig for solution.

Re: Well I broke pkexec somehow, synaptic opens without a pa

Thu Sep 22, 2016 6:40 pm

I just have a launcher in the panel that uses gksu but the main menu still uses pkexec, I think. And yes there is a stay logged in option but you have to relogin after a reboot.

Re: Well I broke pkexec somehow, synaptic opens without a pa

Thu Sep 22, 2016 7:30 pm

golinux wrote:I just have a launcher in the panel that uses gksu but the main menu still uses pkexec, I think. And yes there is a stay logged in option but you have to relogin after a reboot.


Same here for the moment, have to completely replace the .desktop file in usr/share/applications to migrate the change to the menu automatically.

I looked all through the polkit files and didn't find anything, the .gconf folder in home had a little different file in the gksu section, but changing that didn't work, there was also a tiny hidden file in home in the problem install, a ".su-to-root.rc" file I hadn't seen before, the only program that uses that in the menu is Bleachbit root, so I guess using it is where that came from, deleting it didn't help either.

Re: Well I broke pkexec somehow, synaptic opens without a pa

Thu Sep 22, 2016 9:50 pm

I don't know much about pkexec, but I think it's missing in Refracta because it requires (or required 2 years ago) some systemd stuff. I made gparted-gksu.desktop and synaptic-gksu.desktop so they wouldn't get clobbered on updates. To the original .desktop files, add
Code:
NoDisplay=true
so you don't see it in the menu.

Re: Well I broke pkexec somehow, synaptic opens without a pa

Thu Sep 22, 2016 10:02 pm

fsmithred wrote:I don't know much about pkexec, but I think it's missing in Refracta because it requires (or required 2 years ago) some systemd stuff. I made gparted-gksu.desktop and synaptic-gksu.desktop so they wouldn't get clobbered on updates. To the original .desktop files, add
Code:
NoDisplay=true
so you don't see it in the menu.


Now why didn't I think of that? That'll work perfect, thanks!

I think pkexec is installed by default with the mate-policy-kit, so maybe it's not in xfce? It's definitely in there on a Devuan install with the mate desktop, haven't tried a Devuan install with any of the other DE's.

Mate still has some minor dependencies here and there on some gnome libraries too, some I can't get rid of, but found several that I could, don't know why they're still there....maybe some of the other stuff I dumped needed them.

Re: Well I broke pkexec somehow, synaptic opens without a pa

Thu Sep 22, 2016 10:59 pm

the synaptic package installs 2 different binaries:
/usr/bin/synaptic-pkexec
and
/usr/sbin/synaptic
If (when) you are truly logged in as root, check env (setenv) and notice whether /usr/sbin is absent from the PATH= line, eh
Check again when "you are you" but are using a terminal emulator via gksu (and/or via sudo and/or via pkexec and/or via su)
and you'll notice the difference(s)

By default (what's installed), the .desktop file for synaptic probably points to Exec=/usr/bin/synaptic-pkexec
and it sidesteps (diverts the auth internally, thru pkexec) the need to use gksu.
If you change the .desktop so that it points to Exec=/usr/sbin/synaptic instead, makes sense a different (possibly broken) behavior would result.

i'm concerned that if an update to synaptic gets pushed from upstream, that it will wipe out any new .desktop and menu entry I make and revert to pkexec.

Me too! Having customized files being overwritten by package installers is one of my top peeves.
On a live/persistent/frugal system... I'm screwed, but if you're dealing with an installed system (and filesystem is ext4 or similarly capable fs)
you should be able to sudo chmod +i /some/file/we/want/to/protect/against/being/overwritten
^----- tmpfs does not support use of extended attributes, including +i (immutable)

I've read the docs.
A sysadmin is supposed to (is expected to) place any customized .desktop files in /usr/local/share/applications
and users are supposed to place any customized .desktop files under each his/her home directory
...and those will take precedence, and pkg installer won't disturb those locations.
Fun, fun, fun. Let's maintain eleventeen copies of every blessed thang, shall we?

If you do elect to chmod +i some file(s) residing under usr/share/*
...brace yourself, eventually you'll experience "brakage". The pre/post-install of some packages are brittle, so rigid that installation a pkg may fail entirely -- without sufficient warning/errmsg -- just because the attempt to copy a .desktop file into place failed)

The above is a poor (petty) example.
Really what I've been incensed by, and now wish to guard against, is finding that an update has overwritten my customized /usr/share/docs/* files.
And, yes, package installation will often fail due to presence of +i chmodded doc files.
Post a reply