Using pkexec

[GDPR-ohya4wai4eiJ]

If pkexec wouldn't require to permanently run the polycikit process in the background then I would think about to replace gksu with it.

[zika]

I made it executable and now all I have to do is enter ,

rootgedit

in terminal . (That is what I named the file). But you have to do this first..

ventrical@ventrical-desktop:~$ sudo chmod +x /usr/local/bin/rootgedit
##makes the text file rootgedit executable

[sudo] password for ventrical: 
ventrical@ventrical-desktop:~$ sudo updatedb
##updates the datatbase

ventrical@ventrical-desktop:~$ rootgedit
## executes  the terminal code 


ventrical@ventrical-desktop:~$

Simply , rootgedit executes,

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit

You must have missed my advice about alias...
Updatedb was needed because...?

[ventrical]

You must have missed my advice about alias...
Updatedb was needed because...?

..

Honestly .. I'm just experimenting with stuff here. The updatedb was for a windows launcher. I am working on making that script a Unity panel launch item. I'm just trying different things. Thanks for asking.

From:


https://help.ubuntu.com/community/HowToAddaLauncher

1. Make the file executable by typing the following in the terminal:
   sudo chmod +x /usr/local/bin/sampleprogram
2. In the Create Launcher window, fill Command with /usr/local/bin/sampleprogram (or just sampleprogram, but be sure to update your database before that by typing the following in the terminal:
   sudo updatedb

I'll have to re-read your advice about alias.

Regards..

[ventrical]

You've made me play with pkexec (Trusty is the onla version I have at hand here where i am) and:

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit /etc/rc.local

works where else I get

~$ pkexec gedit /etc/rc.local
error: XDG_RUNTIME_DIR not set in the environment.
Unable to init server: Could not connect: Connection refused
(gedit:30178): Gtk-WARNING **: cannot open display:

...
Will investigate further, working line I derived from reading manual...
Update₁:
Alias:

alias pkx='pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY $i'

works nicely[code]

Oh... so does the above assign pkx to pkexec (I would assume)? If I understand you correctly, I would not need to make a shell script then.

Regards..

Edit:

Ok.. yes .. very kewl zika !

ventrical@ventrical-desktop:~$ pkx gedit
ventrical@ventrical-desktop:~$ pkx nautilus

(nautilus:4221): Gtk-WARNING **: Failed to register client: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
Nautilus-Share-Message: Called "net usershare info" but it failed: 'net usershare' returned error 255: net usershare: cannot open usershare directory /var/lib/samba/usershares. Error No such file or directory
Please ask your system administrator to enable user sharing.

^C
ventrical@ventrical-desktop:~$

[grahammechanical]

Here is some useless information from my experiments.

If I run nautilus from the terminal I do not get Gtk-WARNING when the application loads or Glib-CRITICAL when the application closes.
If I run sudo nautilus or pkexec nautilus I get both Gtk-WARNING when the application loads and Glib-CRITICAL when the application closes.
if I run gksudo nautilus or gksu nautilus I do not get Gtk-WARNING when the application loads but I do get Glib-CRITICAL when the application closes.

As I said, useless information. Some more useless information.

I do not get any of those messages whichever way I run Gedit from the terminal. Not even with pkexec gedit. So, the script that I used to create a Gedit Polkit policy is a fine script. And there is an already existing Polkit policy for Synaptic. There are no error messages when using pkexec synaptic.

We are using a Polkit policy to allow an application to run with administrator privileges. The official Polkit policies are used to limit the power of certain utilities. For example, USB Creator is not allowed to install the bootloader, format the device, write an image to the device, mount the device. Which makes it a useless utility until it receives admin authorisation.

 <defaults>
      <allow_any>no</allow_any>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>

[zika]

If I run

sudo nautilus

or

pkexec nautilus

I get both Gtk-WARNING when the application loads and Glib-CRITICAL when the application closes.

To repeat: using

sudo nautilus

can (now even more than before) get You in the position to make more damage than any warning can proclaim...
Disclaimer: I am not writing this to warn You but to warn anyone else just casually reading this...
Why am I pro alias (and using pkexec just with switches, naming alias so that no new command will be named that way) and not pro devoting myself to (as far as I can see quite OK script You wrote? Just because all this is a work in progress and once You write that script and forget about it, You can get into trouble without even remembering what You did change ad how that affect new stuff that is rolling from behind the hill... Not to mention that upgrade of some package could/will destroy that setting even without warning You about that... Been there, done that...

[grahammechanical]

@zika

I do not disagree with anything that you have written. I notice this from wikipedia

Polkit has been criticized for contravening the Unix philosophy of "doing one task and doing it well". The criticism is applied because Polkit has a primary task of restricting root processes as an "authority". A secondary (but easily mistaken for its primary) task is to provide the "authorization", allowing users to obtain temporary privileges. This criticism has been contested by Polkit's developer.

I am not concerned about Unix ethics. What really does worry me is the fact that in other sections of the forum users are often advised to edit system files. But gksu is no longer installed by default and if it gets broken beyond repair at some point in the future will users be advised to run sudo gedit or sudo nautilus because it is easy to advise that than explain how to set gedit or nautilus with a Polkit policy?

Nautilus is chained up because when we try to open certain system folders it refuses to do that and does not ask the user to authenticate. So, nautilus does not need a Polkit policy limiting its use because the limitations are built in. Is that true of other file managers?

Just to be clear. I do not claim credit for that script. It was put forward some time ago by someone when we (here in U+1) first noticed that gksu was not installed by default and it was pointed out that pkexec was there to be used instead.

EDIT: For reference because a little knowledge is a dangerous thing,

http://meta.askubuntu.com/questions/...y-default?cb=1

http://askubuntu.com/questions/28430...led-by-default

http://www.psychocats.net/ubuntu/graphicalsudo

That psychocats tutorial does not explain why we get those error messages but it certainly explains why we still get those error messages = developers not bothered to fix the two bugs.

Regards.

[ventrical]

Here is a counterpoint to the 'don't use sudo' argument by Vincent Danen.

http://www.techrepublic.com/blog/lin...ight-on-sudo/#.


So there's lots of stuff, pro and con, out there.

Regards..

[bapoumba]

That psychocats tutorial does not explain why we get those error messages but it certainly explains why we still get those error messages = developers not bothered to fix the two bugs.

Sorry to stir the thread off tracks here, one thing I have been wandering about but have no real answer for : would sudo -H work opening graphical apps ?

‑H, ‑-set-home
Request that the security policy set the HOME environment variable to the home directory specified by the target user's password database entry. Depending on the policy, this may be the default behavior.

[mc4man]

Sorry to stir the thread off tracks here, one thing I have been wandering about but have no real answer for : would sudo -H work opening graphical apps ?

I'd think sudo -H nautilus or gedit is still good as is
sudo -i
nautilus or gedit
Any of those or pkexec seems better than gksudo atm.

As far as messages -
GLib-CRITICAL **: Source ID ... seems to be an issue created with glib 2.40+, affects several apps. It's up to the app to fix so that likely precludes any fixes for nautilus or gedit.
The Gtk-WARNING **: Failed to register client: seems to be a harmless warning, again seen with some other apps

The error: XDG_RUNTIME_DIR not set in the environment, ect. seems to come from manually creating a policy for nautilus, when the policy is installed with nautilus (nautilus-data) then it doesn't occur, "pkexec nautilus" works fine, no env is needed (which to me is better as I never run from terminal, alt+F2 or nautilus-actions via context menu.

Why that is not yet sure, if anyone wanted to see I have the start of a 14.10 proposed ppa that currently only has nautilus in it. (several additional patches inc. enabling pkexec
https://launchpad.net/~mc3man/+archive/uptopic-props
If inclined to test one can then use ppa-purge to return to repo version (nautilus-data package contains the policy so it must also be upgraded