[NCLUG] Need to write to non-owned file
bsimpson at att.net
bsimpson at att.net
Mon May 14 12:24:31 MDT 2007
>
> > I am writing a C++ application that must read a file, alter it,
> > then write it back out. This file may be owned by another user,
> > and be writable only by that user. In this case I display a
> > popup to enter that user's password. Once I have that password,
> > how do I write to that user's file? In a shell environment, it's
> > easy to switch users. I need to do that within an application.
>
> The answer is that you don't actually want to do this. Really. It's
> going to be a *huge* security hole.
I'd like to understand why.
> Consider the case where the user of your application tricks your program
> into editing /etc/passwd or something like that.
But /etc/passwd is owned by root. Wouldn't you need root's password?
And if you had root's password, you wouldn't need my application to
wreak havoc on the system.
I'd like to understand in general why this is a bad idea.
I'll also mention that in this specific case it probably is a
don't care. The environment is a small satellite operations room
where the machine is physically by the operator, and it is a closed
environment - not connected to the Internet. We screen our
operators, since they would have more than just this opportunity
to mess things up.
The file to be written out is one of several configuration files.
The engineers want a particular one not to be readily modifiable
by the operators.
> Equally, you probably don't want your program to read the user's
> password and authenticate the user; it's a pain. It would require (at
> least part of) your program running as root, calling a bunch of complex
> APIs like setuid/seteuid/setgid/setegid, and probably a bunch of other
> complex stuff.
That may explain why I didn't see any examples of doing this in
my limited search. If, in general, it's a bad idea, I'd like to
get a handle on why.
> Instead, you're probably better off spawning a copy of su/sudo/login
> (possibly within a spawned xterm etc. if it's a GUI app) and having that
> prompt the user for the password, and running a command to write/edit
> the file.
That might be the way to go...
Brian S
More information about the NCLUG
mailing list