[NCLUG] Need to write to non-owned file

[Katy G. B.]

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.
>
> -bc
>
> 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 
>>> 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...
>
> WARNING: All HTML emails get auto deleted.  DO NOT SEND HTML MAIL.
> WARNING: Emails with large typo counts/spelling errors will also be 
> deleted.
> _______________________________________________
> NCLUG mailing list       NCLUG at nclug.org
>
> To unsubscribe, subscribe, or modify your settings, go to: 
> http://www.nclug.org/mailman/listinfo/nclug