On 04May2017 21:05, Wildman <best_...@yahoo.com> wrote:
On Fri, 05 May 2017 09:58:02 +1000, Chris Angelico wrote:
On Fri, May 5, 2017 at 9:50 AM, Wildman via Python-list
<python-list@python.org> wrote:
I'm afraid that won't work. The user environment is different
than root. A different set of variables. However you have
given me a possible workaround. You can't create a variable
for root unless you are root so that approach is out. But
it might be possible to create the variable for the user
and access it as root. I don't have a lot of experience
using os.environ, but I am going to at it closer.
When you start a subprocess, it inherits your environment. So you can
create an environment variable for yourself, then start the other
process.
If you go through sudo the environment gets very scubbed for security reasons.
You can turn that off in the config, but it is not a great idea.
I solved this problem by passing the user name to the second
instance as a command line argument. Works perfectly. It
escapes me why I didn't think of this sooner. I solved the
os.login problem by not using os.login, since I no longer
need it. :-)
I actually thought about suggesting this and refrained: how do you
avoid user B invoking your program with user A's login name as an
argument? Reliably? Without a way to check that the command line argument is
not a lie, this is an avenue to breaking your security. And to check it you're
back into "who invoked me?" territory. And further, if you _can_ check it, do
you need the argument at all?
So I didn't think it was useful.
But read Cameron's cautionary notes and basically just don't do this.
It has been my experience that Linux users tend to be a little
more conscious of security matters and know what the implications
are when doing anything as root. I expect the user will know the
risks if they choose to restart the program as root. I believe
in user choice.
User choice is great provided the user _is_ actually informed and properly
understands the risks. Ship secure, let the user turn things off carefully. If
people truly want to shoot themselves in the foot nothing will really prevent
them. But don't give them a loaded gun with the safety catch off. Ideally,
don't give them a gun at all. Yeah, poor choice of metaphor, apologies in
advance.
To make this more pointed, you're making this thing but still learning about
the security implications, and what will and will not work. A third party using
your program will know even less (for example, they won't inherently know what
your program does and therefore whether _they_ should trust it in _their_
environment).
We have a nice "Securiing UNIX systems" book on a shelf here. It has chapters
for Solaris, various Linuxes, FreeBSD, OpenBSD. Pleasingly the OpenBSD one
roughly starts: "install OpenBSD; you are now secure; turn more things on as
needed carefully". Versus the other chapters which say: "install, then do all
this stuff". And OpenBSD users are generally far more security conscious than
Linux users, or they wouldn't have gone to OpenBSD.
I'm not saying abandon your project. I'm wanting you to think very carefully
about your security decisions, particularly with things that automatically run
as root. In particular, don't just think about how to get the behaviour you
want; think about how to _break_ it - get root as the wrong person, or get root
to give you information you should not have. Etc.
Cheers,
Cameron Simpson <c...@zip.com.au>
--
https://mail.python.org/mailman/listinfo/python-list
