Hi Ralph,
Hopefully my quotes work this time.
I see, that makes sense. The shebang line will tell it what to use to run the
script anyway. I also see what you mean about identifying the parent process -
as long as they're authorised, other applications should be able to do it too.
even if you could state just the actions that you feel you
requested with pkexec, they were granted to the session and other
parties in the session may be legally using them too. They may even
have beat you to it and your pkexec found a temporary authorisation
already existed thanks to them.
That's true. However, I think it's probably better to call it at particular
times than either ask for a password several times in a row, or leave the
script wide open for 5 minutes :). To illustrate:
Say the GUI has to run several mount commands in a row. I can either:
1. Ask for the password several times - don't use temporary authorisation.
2. Use temporary authorisation, and ask once, leaving the temporary
authorisation for this session for 5 minutes (a bad idea, surely?)
3. As above, but revoke temporary authorisation immediately after the
commands have finished. Not ideal, and means the password has to be entered
again soon, but more secure?
I can see why it could annoy the user by making them ask for the password again
when they otherwise wouldn't have to, but I don't see a better alternative. I
know this is a flawed design and could annoy people by making them enter their
password again, but I'd rather it lean towards being annoying than risk it
being insecure. Am I being a bit paranoid here?
Hamish
On 17/05/18 12:07, Ralph Corderoy wrote:
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
