Hi Hamish,
I now know more that I want to about policykit.
This will amuse Tim. :-)
> > These sessions are what loginctl(1) lists, and referred to by
> > `allow_any', `allow_active', and `allow_inactive'? What two
> > sessions do you have in mind where it is authorised in one, still
> > needs authorising in the second, and you wonder if it should?
>
> Yes, that's right. So long as I have only active allowed, if I run my
> script with pkexec in one terminal window and authenticate, and then
> open a new window (creating a new session), I have to re-authenticate
> in that window.
Well there we differ. loginctl(1) here doesn't list a new session for
each new X terminal window.
$ loginctl
SESSION UID USER SEAT TTY
c2 1000 ralph seat0
c73 1000 ralph seat0
2 sessions listed.
$
c73 is my X session where I'm typing this, and c2 is a screen(1) that
continues after I log out of X.
I grep'd and found `org.freedesktop.color-manager.install-system-wide'
has `auth_admin_keep' for `allow_active' so I'm using that for the test.
$ pkcheck --list-temp
$ pkcheck -u -a org.freedesktop.color-manager.install-system-wide -p $$
polkit\56retains_authorization_after_challenge=true
polkit\56temporary_authorization_id=tmpauthz3
$
pkcheck(1) caused a GUI authentication prompt to appear and I entered my
user's password. I now have a temporary authorisation that lasts five
minutes.
$ pkcheck --list-temp
authorization id: tmpauthz3
action: org.freedesktop.color-manager.install-system-wide
subject: unix-process:8351:41145575 (-bash)
obtained: 4 sec ago (Thu May 17 09:35:51 2018)
expires: 4 min 55 sec from now (Thu May 17 09:40:50 2018)
$
I open a second X terminal and run the same command, it too sees the
same existing authorisation.
$ pkcheck --list-temp
authorization id: tmpauthz3
action: org.freedesktop.color-manager.install-system-wide
subject: unix-process:8351:41145575 (-bash)
obtained: 31 sec ago (Thu May 17 09:35:51 2018)
expires: 4 min 28 sec from now (Thu May 17 09:40:50 2018)
$
Can you achieve something similar?
> The GUI does run pkexec - to run the privileged processes it requires
> to get the work done - it's a GUI for GNU ddrescue. I worded that
> badly - what I'm concerned about is that all I can do right now is
> check that "DDRescue-GUI.py" (the name of the GUI) is in the process
> list. Someone could intentionally write a python script with that name
> to fool the pkexec wrapper into doing something when it shouldn't - I
> don't want it to do anything if the GUI isn't running, to prevent
> security issues.
I don't think you have that choice, and it's the wrong way of looking at
things.
You've provided a non-GUI wrapper command to run ddrescue(1) called
runasroot_linux.sh. (I'd recommend dropping the `.sh' suffix.)
Have you written the XML shenanigans to define an `<action>', e.g.
`id=org.hamish.runasroot_linux.sh', with an `<annotation>' like
<annotate
key="org.freedesktop.policykit.exec.path">/usr/local/bin/runasroot_linux.sh</annotate>
pkexec(1) will take the program it's asked to run and use its path to
search all `<action>'s for an `<annotation>' with a key of
`org.freedesktop.policykit.exec.path' that matches. That `<action>' is
then used, e.g. to define how the user must authenticate.
https://cgit.freedesktop.org/polkit/tree/src/programs/pkexec.c#n268
Once you've done that, your Python GUI can run `pkexec
runasroot_linux.sh some args'. I think pkexec will find it in
/usr/local/bin, say, due to $PATH and then search the `<action>'s.
But my shell script can also do `pkexec runasroot_linux.sh other args'
to make use of the service you've provided. This is intentional. There
is no security in insisting only your GUI makes use of
runasroot_linux.sh, and it's hard to achieve, as you're aware.
If you're concerned that I can do `pkexec runasroot_linux.sh some
nefarious command' and your org.hamish.runasroot_linux.sh policy will be
used when it's nothing to do with ddrescue(1) then the problem is your
runasroot_linux.sh. The name gives it away. You've a `do anything I
throw at you' mechanism with a policy that only applies for
ddrescue-ing. The script needs to only allow the limited ddrescue
operations you want.
If it helps, there's also a `org.freedesktop.policykit.exec.argv1'
annotation that further restricts the search above to those where the
first argument to the command matches. I expect this is to allow a
lower bar for running `ddrescue-wrapper list' to `ddrescue-wrapper
format', for example.
Cheers, Ralph.
--
Next meeting: Bournemouth, Tuesday, 2018-06-05 20:00
Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/
New thread: mailto:dorset@mailman.lug.org.uk / CHECK IF YOU'RE REPLYING
Reporting bugs well: http://goo.gl/4Xue / TO THE LIST OR THE AUTHOR
