Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There's an executable that's usually run by user A and writers in a directory only readable, writable, etc. by user A. Is it possible to allow user B in the same group to run the executable as user A so that it writes in the same directories, etc., without user B knowing the password of user A and without having access to root (i.e. cannot use visudo)?

share|improve this question
    
Would making the directory group-writable meet your requirements? – Keith Thompson Jan 14 '13 at 0:32
    
@KeithThompson I would prefer to have the resulting files owned by user A, though I may have to do that. – pythonic metaphor Jan 14 '13 at 0:35
up vote 3 down vote accepted

Yes, this can be done using chmod u+s to setuid the executable to run with the effective ID of the owner of the executable. More here and here.

share|improve this answer
1  
Note that this allows anyone with execute permission for the executable to run it as A. As with any security setting, paranoia is healthy. – Keith Thompson Jan 14 '13 at 0:42
    
Odd. Wonder why someone downvoted my answer. – Nicole Hamilton Jan 14 '13 at 1:22
    
I have observed that this does not always work as intended in shell scripts or perl scripts. Thus, a restricted sudo would be the approach without a lot of problems. – mdpc Jan 14 '13 at 1:24
    
@mdpc Can you be more specific or perhaps give an example of what you mean by not working as intended? – Nicole Hamilton Jan 14 '13 at 1:33
    
@NicoleHamilton: It's explained in the Unix FAQ here. – Keith Thompson Jan 14 '13 at 2:52

Setting up sudo to allow B to execute a particular command as A would probably be the best and safest approach, but you said you can't use visudo.

Assuming your system has a working ssh server, you could add B's public key to /home/A/.ssh/authorized_keys. B could then run:

ssh A@localhost some_command

without having to know A's password.

The trouble is that this gives B full access to A's account. It's not quite as bad as giving B A's password.

There may be ways to set up ssh to permit B to run only certain commands, but I don't know what they are.

(chmod u+s, as Nicole's answer suggests, is probably cleaner; I should have thought of it.)

share|improve this answer
    
chmod is quicker/easier. I don't know about cleaner. – tink Jan 14 '13 at 1:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .