Hi Hamish,
> I was wrong about the sessions - that was a faulty assumption as I
> didn't know how to check. Yes, I have the same behaviour as you. The
> second terminal window can see the authorisation, but if I run the
> command again from there, I have to enter my password, whereas if I
> run it from the other terminal ewhere I already ran it, I get
> authorised using the temporary authorisation...
That's because the program being checked is specified with `$$' so the
second terminal is asking for a different check, but can see the first
with `--list-temp'. Using the same process ID in both has the second
avoid prompting for a password, e.g. get a long-running PID,
$ cat &
[1] 14058
$
Then be prompted in the first terminal,
$ pkcheck -u -a org.freedesktop.color-manager.install-system-wide -p 14058
but not the second if the same command is run there.
> Yes, that extra annotation will be helpful, and may be just the
> ticket. I couldn't find a list of valid annotations anywhere, so
> where did you find that?
pkexec(1) talks about the `org.freedesktop.policykit.exec.path'
annotation.
> ddrescue was just an example - the wrapper script has to be able to
> call quite a few different programs
OK.
> in ways that make it hard to check whether the GUI is requesting or an
> attacker. I've made multiple files, so if I combine the polkit
> annotation with checks in the files, and check to see if the GUI is
> running, then I may have something workable.
No, you're still not getting the key thing. Your non-GUI `rescue'
command, that polkit is taught about, doesn't care what is running it
and doesn't need to check. Stop trying to check it's your other program
that's running it.
Imagine you didn't have to write the non-GUI `rescue', but someone else
already had and provided polkit rules to cover the various ways of
running it. You'd just be writing a GUI and using pkexec(1) to make use
of a existing service. I could write a competing GUI that also used
non-GUI `rescue' and pkexec(1) to do the hard work. Neither pkexec(1)
nor the non-GUI `rescue' would care which of us is running it, and quite
right too.
> Why drop the ".sh" off the end, by the way?
The same reason it's not ls.exe, autoheader.pl, egrep.sh, or hg.py. :-)
Suffixes are useful for source code to help the build system know what
to do, but they don't belong in the executable's name; that style is
from an operating system that relies on the suffix to know how to run
the file, and a shell where the command is specified without the suffix.
Using `foo.sh' would also mean I couldn't re-write it in another
language without changing its name.
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
