os.getlogin() Error

[Cameron Simpson]

On 04May2017 21:05, Wildman <best_lay at 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 at 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 <cs at zip.com.au>