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