[NCLUG] Need to write to non-owned file
Katy G. B.
katy at dystonia-dreams.org
Tue May 15 22:41:32 MDT 2007
the way i would resolve this issue, and the arguable 'correct' way is
really simply, after getting the users passwd, permissions, fork your
app or create a child process running as that user. do whatever you
need to o and than have the child process return control to your
progie. though i'm still like in major *scratches head* mode for like
why. but whatever, that's the correct way to handle that if you like
totally want to stay inside your c++ prog. otherwise you could also
just like have your app write a `tmp` perl(or whatever) to just like do
whatever you wanted done and than exec that. but again yeah it all
sounds like hacks for stuff you "shouldn't" do, so i'd stick with
running a child proc. ig you like really have to do something like this
than just like do it as 'right' as you can.
Benson Chow wrote:
> The long explanation:
> Programs like 'passwd' is basically doing what you want to do, except
> the target user is 'root'. However, to do what you want to do, even
> though the target user is another non-privledged account, the pathway
> has been said and is the same as 'passwd' - switch to root first, then
> setuid to the target user (even this may not be necessary, just edit
> the file as root!).
> The reason why this is "bad" is that it's not inherently bad - after
> all, it _is_ the only way to edit someone else's file when you have no
> permission otherwise (such as file/acl permissions). The reason why
> it _is_ bad is that it's usually HARD to prevent the program to not
> "accidently" give any user of this program root privledges.
> Let me tell you, given a naive implementation of a setuid program
> there are a lot of ways to crack into it and get root. Everywhere
> from buffer overflows to timing attacks, you'll have to ensure every
> single method is blocked, from making sure all buffers are bounded and
> all file writes are atomic (with itself _and_ other programs), TO
> START WITH! There's MUCH more to it than just these two examples!
> If you trust your users as 'root' then by all means go for it! It's
> actually very simple... And 'setuid' is what you need to do. But you
> might as well give everyone the root password.
> BTW - even sudo solutions may not be secure, though 'sudoedit' as
> suggested has been attempted to be cleaned up of all potential
> privledge escalations much like the 'passwd' program.
> Try hard to not need to go through this route if you don't trust your
> users with root access, else you'll have to go through a lot of
> auditing. Maybe you like to do the auditing. It's _hard_ and it's the
> cause of why there are so many viruses floating around that exploit
> these bugs.
> On Mon, 14 May 2007, bsimpson at att.net wrote:
>>> 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
>>> 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
>>> prompt the user for the password, and running a command to write/edit
>>> the file.
>> That might be the way to go...
> WARNING: All HTML emails get auto deleted. DO NOT SEND HTML MAIL.
> WARNING: Emails with large typo counts/spelling errors will also be
> NCLUG mailing list NCLUG at nclug.org
> To unsubscribe, subscribe, or modify your settings, go to:
More information about the NCLUG