Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. 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

I'm trying to allow my user (via sudo, launched in a script) to copy a file from their home to a web directory.

Command would be:

sudo cp /home/$LOGNAME/file_source /var/www/$LOGNAME_file_dest

So i added the following line in my sudoers file:

%users ALL=(ALL)NOPASSWD:/bin/cp /home/$LOGNAME/file_source /var/www/$LOGNAME_file_dest

This doesn't quite works, because sudo asks me for a password and it should not. I guess this is a problem with the $LOGNAME variable that is not interpreted in sudoer file or somehthing like that.

I almost forgot to mention that I'm a control freak, this has to be a very strict condition, no * or anything else tolerated.

Has anyone a solution to such a problem or should I go the painful way and allow 1 by 1 user to cp his file to the /var/www directory?

share|improve this question

Shell variables are interpreted by your shell, and are never seen by sudo or any other program launched with them. That is, when doing foo=bar; echo "$foo", echo never knows that the data it was passed came from a variable called "foo", because the shell expands it before echo is even executed. For this reason, it isn't possible to make shell variables work transparently in your sudoers file.

Also, since $LOGNAME could be anything, what you are wanting to do is essentially equivalent to using a star after /home in your sudoers, regardless of whether you use it or not. I would not recommend doing this, because you can essentially copy anything to anywhere as root, which is a huge security risk (since $LOGNAME can contain ..). Ultimately, you say you don't want to use *, but the action you are wanting to take is equally dangerous.

The best option is to allow read access to whatever is at /home/$LOGNAME/file_source, and write access for these users to /var/www. You could have a www-logs group that has group read and group write for these paths, respectively.

share|improve this answer
Hi Chris, thank you very much for the answer. This is all sad news for me because alowing users write access to /var/www won't do either for security constraints. Humm I understand what you are explaining real good. Guess I'll have to figure something out. Maybe a job running every 1 min/30s synchronyzing my file from users home to /var/www running in root account or else. Think it could be a way... – trox May 29 '13 at 3:27
Also, what about env_keep? $LOGNAME, $USER and so on are env varibale... Nevrmind it's used later on when the command is executed... – trox May 29 '13 at 3:43
Isn't there any way to use regexp for sudo condition checks, that would be really usefull, at least to me :) – trox May 29 '13 at 4:13
$LOGNAME can be arbitrary, how would that be safer? – Chris Down May 29 '13 at 5:15
@trox If all you're attempting to do is let them copy files into a directory they should have write access to, it sounds like a job for the scripted application of POSIX ACL's. You don't have to give them write access to entire directory trees but you can give just these users write access to particular directories. – Bratchley May 29 '13 at 11:25
up vote 1 down vote accepted

Joel Davis has the correct answer, thank you all very much for your kind help! "scripted application of POSIX ACL's" that is!

And: http://stackoverflow.com/questions/869536/linux-directory-permissions-read-write-but-not-delete

Example: (Create files, once written, they are read only, but CAN be deleted by owner, but not others.)

setfacl --set u::rwxs,g::rwx /controlled
setfacl -d --set u::r-x,g::r-x,o::- /controlled

This is exactly what I need to do.

Thank you all very much for you help, I should have asked this question differently.

share|improve this answer

Create a script which performs the copying after any necessary checks, and grant sudo access to that.

Note that privileged shell scripts are considered bad practice; you might want to go for e. g. Python or Perl instead.

The environment created by sudo should already prevent the user from overriding library paths etc but you may want to take some extra steps to bolt it down so that only a minimal set of system library paths are allowed.

share|improve this answer
Yes that was also somehting I had in mind but prefered not to do. – trox May 29 '13 at 22:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.