oberon-manjaro
commented
6 years ago @Chrysostomus is there a way to store the password in keyring with zensu? Atm it is asking for password every time again ... ?
Closed oberon-manjaro closed 5 years ago
oberon-manjaro
commented
6 years ago @Chrysostomus is there a way to store the password in keyring with zensu? Atm it is asking for password every time again ... ?
Chrysostomus
commented
6 years ago Possible? Yes. Possible to do securely? Maybe, I'll have to look into it. Ideas are welcome
Chrysostomus
commented
6 years ago Gnome-keyring could possibly be used for this? It could be added as optdepend.
I wonder if it would be better if zensu checked if there is a polkit agent running, and if so, just prepended pkexec to command instead of sudo with password query? Advent of polkit is why gksu was decrepated in the first place. This would get around the problem of apps that still depend on gksu.
oberon-manjaro
commented
6 years ago Well, I realize that pkexec also normally doesn't remember passwords, or does it? Maybe that's just sudo behaviour? In any case
if so, just prepended pkexec to command
For some applications I have tried sofar that would seem to work, however for some reason:
[bernhard@manjaro-sx ~]$ pkexec pcmanfm
Cannot open display:Pass might be another option to store passwords here...
Ste74
commented
6 years ago Pkexec use a xml file wich contain the rules for work.. If app not provide the xml file pkexec not work.. Sudo is not better to run the graphical app for security reason.. Gksu etc. Solve this but again for security reason is not better so wayland and gnome want pkexec as standard...
Chrysostomus
commented
6 years ago I'm in a bit weird place with the adoption of zensu. I wrote it, but if it's going to be used more widely, it needs some significant improvement. It was originally designed to avoid the gtk2 dependency of gksu, then updated to avoid the webkit dependency of zenity. It was a bit of a hack to begin with.
fhdk
commented
6 years ago As long as developers of different apps does not provide the files for polkit it is difficult to launch graphical apps which requires superuser rights.
Recently we have had issues with apps requesting password twice - could this be due to those missing polkit files or maybe poorly written files?
My experience in these authentication situations is that when an app requests password twice it is usually the root password that authenticates.
Wouldn't be reasonable to use pkexec and if that fails use sudo?
For example - on my openbox install
~ >>> pkexec thunar
Thunar: Failed to initialize Xfconf: Cannot autolaunch D-Bus without X11 $DISPLAY
Unable to init server: Could not connect: Connection refused
(thunar:7049): Gtk-WARNING **: 18:24:51.771: cannot open display:
~ >>> If a password can be piped to pkexec, then that would be viable:
1) test for polkit agent 2) if available, pipe the password to pkexec and fall back to sudo if necessary 3) if no polkit agent running, use sudo
fhdk
commented
6 years ago https://wiki.archlinux.org/index.php/Polkit
It appears it is possible to pipe to pkexec
https://code.launchpad.net/~roadmr/checkbox/1097816-pkexec/+merge/171930
Another thing maybe related to my experience of being requested password twice
https://www.freedesktop.org/software/polkit/docs/0.111/pkexec.1.html
pkexec allows an authorized user to execute PROGRAM as another user. If username is not specified, then the program will be executed as the administrative super user, root.
So if pkexec is called without --user $USER then root is assumed!
pkexec thunarversus
pkexec --user fh thunarMore promising is the return value
Upon successful completion, the return value is the return value of PROGRAM. If the calling process is not authorized or an authorization could not be obtained through authentication or an error occured, pkexec exits with a return value of 127. If the authorization could not be obtained because the user dismissed the authentication dialog, pkexec exits with a return value of 126.
fhdk
commented
6 years ago So to make any program able to run with elevated rights, as @Ste74 already noted, it requires the presence of a policy file.
https://askubuntu.com/questions/287845/how-to-configure-pkexec
This one works
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY thunarThis will probably make pkexec as unsafe as gksu
If executed with a user argument and trying to access e.g. gparted
pkexec --user fh env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gpartedwill result in an error and a new prompt saying - root credentials is needed - superuser is not enough.
fhdk
commented
6 years ago Wayland + Gnome
https://ubuntuforums.org/showthread.php?t=2374812
if [ $XDG_SESSION_TYPE = "wayland" ]; then xhost +si:localuser:root; fi
fabiscafe
commented
6 years ago Why do we need a gksu replacement in the first place? I mean there is a good reason that it's not here anymore and linux moves on to polkit. Also I dont like the approach to hijack pkexec, just to make something run on xwayland
Chrysostomus
commented
6 years ago 1) repos and AUR still have some packages that use gksu internally even though they should not 2) some editions don't use polkit by default
That's the use case: transition period
fabiscafe
commented
6 years ago To be realistic, ask yourself: Is there any progress for these missing parts to do the change to polkit? If yes -> transitioning phase is OK, if no: remove them from the repo, put them to the AUR.
gksu is in !aur, so thats nothing we have to care about.
For root terminal stuff we really should write bugreports, because calling them with gksu directly seems to be wrong, when its so easy to just run sudo -i, pkexec inside them and get root permissions
for gnome terminal
gnome-terminal -- pkexec
And gnome-terminal will actn as a root terminal.
For a polkit wrapper: please make sure you dont make things worse for wayland users, we dont want to start apps via Xwayland, because of something. One of the next steps on the wayland roadmap is to remove the xwayland dependency, so if we create here new dependencies for X, someone has to work on it later again.
That transitioning period is ongoing for about 10years and we're already at stage 4 (or somewhere at stage 6 of 10 in the real list, but I cant find this list anymore :-1:)
fhdk
commented
6 years ago @Chrysostomus
http://aur.archlinux.org/packages/gksu-polkit-git
@Tids Does work with Wayland?
Add: https://wiki.gnome.org/Attic/gksu
@oberon2007 I have build the gksu-polkit package - could you test it - have an opinion maybe.
In unstable as gksu-polkit and source at https://github.com/fhdk/gksu-polkit
oberon-manjaro
commented
6 years ago This looks great, I like! :smiley: :+1: How did you manage to inherit this repo? I was already looking at the AUR package and couldn't find anything useful via debian as it looks like they have restructured there git and also abandoned the package. With versioning we normally don't necessarily follow the AUR at all costs. At the same time we try to avoid epoch if possible. So I would suggest you drop the epoch and bump version to 0.0.3, including the latest commits. Also I'd suggest to include a link /usr/bin/gksu > /usr/bin/gsku-polkit It conflicts gksu anyway and typing 'gksu-polkit' is a little unpractical. Also like that existing config and scripts will contiune to work without modification :nerd_face:
fhdk
commented
6 years ago On Fri, 01 Jun 2018 06:08:49 -0700 Bernhard Landauer notifications@github.com wrote:
This looks great, I like! :smiley: :+1: How did you manage to inherit this repo? I was already looking at the AUR package and couldn't find anything useful via debian as it looks like they have restructured there git and also abandoned the package. With versioning we normally don't necessarily follow the AUR at all costs. At the same time we try to avoid epoch if possible. So I would suggest you drop the epoch and bump version to 0.0.3, including the latest commits. Also I'd suggest to include a link /usr/bin/gksu > /usr/bin/gsku-polkit It conflicts gksu anyway and typing 'gksu-polkit' is a little unpractical. Also like that existing config and scripts will contiune to work without modification :nerd_face:
Already ahead of you.
I have already made an gksu-polkit.install which conflicts gksu and zensu and creates a symlink as you suggested.
-- FH fh@uex.dk
oberon-manjaro
commented
6 years ago an gksu-polkit.install which conflicts gksu and zensu and creates a symlink
Both needs to be done in the PKGBUILD, not an .install. Otherwise pacman will not know of the symlink's existence!
fhdk
commented
6 years ago The .install script has both post_install() and post_remove() which is where it happens
post_install() {
ln -s /usr/bin/gsku-polkit /usr/bin/gksu
}
post_remove() {
rm -f /usr/bin/gksu
}
philmmanjaro
commented
6 years ago @fhdk symlink needs to be added to PKGBUILD and not to the post install script. Also a replace and conflicts with gksu is in order.
oberon-manjaro
commented
6 years ago That's what I mean, yes. It goes inside package() function.
In general, please push your files so we can actually see what we are discussing :smiley:
fhdk
commented
6 years ago Like this?
package() {
cd $pkgname
make DESTDIR="$pkgdir" install
install -Dm644 "$srcdir/gksu-polkit.service" \
"$pkgdir/$(pkg-config systemd --variable=systemdsystemunitdir )/gksu.service"
ln -s gksu-polkit $pkgdir/usr/bin/gksu
}ln -s gksu-polkit $pkgdir/usr/bin/gksu
:wink:
fhdk
commented
6 years ago I noticed that pkg-config was replaced by pkgconf?
The package() function uses pkg-config - should I change it?
fhdk
commented
5 years ago fhdk
commented
5 years ago
gksu has been deprecated so we need to use alternatives. Where pkexec isn't they way to go, zensu seems to be a simple and good option. @manjaro/maintainers
Current state of
manjaro:desktop-settingsrepo:also we have:
and in package lists still:
hits in community repo: