Getting SuperUser Authority From Within Running Python Program

[Laura Creighton]

> 
> I am working on the next release of 'twander' - a user-programmable
> file manager/browser (http://www.tundrware.com/Software/twander).
> I want to be able to temporarily go to super-user status so the
> program can act upon/manage/manipulate root-owned files.

This is the wrong way to think about this.  You need to think very,
very, small and think 'as root I need to change the owner of a list
of files' or 'as root I need to open this file which is owned by root'
or something very tiny and very concrete like this.   Also you need
to consider whether your problem is having those files owned by root
in the first place.

> 
> I have another way to accomplish this - I can write a 'twander'
> macro that issues the necessary 'su' stuff to instantiate
> an image of itself with root permissions.  I was just wondering
> if there was some reasonable (safe) mechanism for doing this within
> a single instance of the program.  This is similar in spirt to
> sysadmin programs under Linux which allow you to enter the root
> password so they can operate on the system without you having
> to to log in the whole session as root.

This is the 'trusted user carries the password in his head' model
of security.  It is convenient, and this is why it is used.  It is
not all that secure and it most definitely does not generalise
to 'ok, let me model my program to be a trusted user that has the
root password in its head'.  No program is that trustworthy.  You
are setting yourself up for a lot of grief here.

You need to think a lot less friendly and a lot more paranoid.
There has got to be a good unix security guide online.  I will
look for one, though in the meantime somebody else should post it 
if they have it ....

> I am curious about one thing you said - that setuid is ok for selected
> (compiled) programs but not scripts.  If the script has appropriate
> limitations on who can modify it, why is setuid/setgid worse for
> scripts than compiled programs?

Well, as a practical matter, on linux systems they are simply ignored 
and will not run.  The reason why this is so, is because there is a
nasty, unavoidable race condition which means between the time the
script invokes Godlike power and it begins to run, somebody can install
their own version of the interpreter.  Then it is game over.  This is
not a theoretical problem.  It happens.  I was busy there on the
front lines when this began happening in the v7/4.1bsd days of unix and 
helped prove that this problem was inevitable, and that there was 
no way to fix it (at that time).  Differently written schedulers
might get around this -- it has been 20 years since I've thought about
this -- but since you simply  cannot get a setuid script in linux, 
was objecting on the practical grounds that 'it doesn't work'...

> 
> Thanks for your time,

My pleasure.

> 
> -- 
> -----------------------------------------------------------------------------
> -
> Tim Daneliuk
> tundra at tundraware.com
> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list

Laura Creighton