Allow users to chmod certain directories via sudoers file
Can anyone provide an example of what I should type in the sudoers file so a specific user (example: smith) can perform a chmod on files located in /data/security/ only?
It seems when I enter smith ALL=NOPASSWD:/bin/chmod 755 /data/security/* smith can perform a chmod on any files, regardless of the directory. A million thanks, Johnny Mac |
First you need to think about what is a file under /data/security/ ? If it has hard links to a filename in some other location then it's debatable whether the file really qualifies. You can solve this problem by having a filesystem mounted at /data/security/ and nothing mounted below it (making the filesystem and the directory tree the same thing).
Then maybe you want to combine "chroot();chdir();chmod()" into one program so that when it is called with sudo it operates on file(s) under /data/security/ by being chrooted there and has no alternative regardless of the command line provided by the user. That's what I'd call the standard way to do it for a C programmer. There is also a thing called "posix capabilities" containing CAP_FOWNER (see http://linux.die.net/man/7/capabilities) which looks as if it will allow chmod by users other than the owner. I suspect this is a worse option than the other. |
Not sure what Command to Type to mount to File System
linosaurusroot,
Sort of new to Linux. What command should I type to mount the directory as a seperate file system? Is it somthing like mount /data/security? Take care, John |
Can you show your /etc/fstab ? And estimate the largest amount of data that might ever exist under /data/security ?
|
Quote:
Quote:
The easiest thing to do would be for you to write a very small shell script with that one command in it. Make it owned by root:root ("chown root:root /path/to/scriptname"), and permissions of 700 (rwx------) ("chmod 700 /path/to/scriptname"), so that ONLY root can run or edit it. That's it. In sudoers, restrict them to that one command, and deny ALL OTHERS, as so: Code:
User_Alias LIMITEDADMINS = username Code:
sudo /path/to/scriptname someargument If you want more users to do it in the future, just add them to the alias group. More commands? Just add another script/command (comma-separated), and you're done. |
Quote:
He doesn't want them to run only one command. He wants them to chmod files under one directory. Once you put "chmod $1 $2" kind of thing in that script you are doomed. |
Quote:
Quote:
Code:
chmod /data/security/$1 |
linosaurusroot
linosaurusroot,
Here you go: /dev/VolGroup00/LogVol00 / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/VolGroup00/LogVol01 swap swap defaults 0 0 |
Quote:
Code:
#!/bin/sh Code:
/data/storage.ext3 /data/security ext3 defaults,loop 1 2 |
Quote:
Code:
smith ALL=NOPASSWD:/bin/chmod 755 /data/security/* Quote:
I think you're assuming that only root has write access in /data/security/ (but we've not been told that by OP). If smith (or an accomplice or even an innocent user) writes there you have the possibility of something in that directory being a symbolic link to something outside the directory. It could even become this while the script is running (which is a race condition - what a C programmer might tackle with fchmod()). I've just tested and chmod does follow symlinks on my system. |
What about
test -f ${1/*\/} && chmod /specific/directory/here/${1/*\/} Although, I'm not too knowledgeable on this, but I presume this wouldn't allow any links nor any directories to be modified, as well as would keep anyone from modifying anything in any sub directories. |
Quote:
What you'd do in C is open() the file (using its name) then test the file descriptor you had that it was the right one and finally do fchmod() on the descriptor (you don't care about the name at this stage). |
Quote:
Also, just ran a few tests and found that even using "test -f", for some odd reason, still chmod'ed the linked file. Quote:
|
Going back to the original qn, it seems to always be the same cmd for the same target(s).
How about inotify/inotifywait instead? http://linux.die.net/man/7/inotify http://linux.die.net/man/1/inotifywait Alternately, how about changing the program that creates/moves/copies the file, to set the perms when it does so. |
Resolved
Please allow me to begin with saying that this site has renewed my faith in the community involvement whose charter is to help others when possible. I think each of your comments above are extrodinary and well thought out along with your constructive critisism many will benefit from those who view this thread. After much thought and consdieration I have decided to implemnet a simple and secure resolution. I have created a script that directs the changes I would have executed if I was at the console. This script can be executed by the general user after performing the sudo command and providing the path and respective script. This script is 700, and located in a folder which the general user can not view (thus not modify).
If I could share the points/credit for solving this problem to all those who replied I would, since each solution would work but based on my limited skill-set and security factors I have implemented TB0ne concept. Going forward I hope to improve my Linux Skills and share everything I know. Take care, Johnny Mac |
You also have a problem with shell metacharacters.
consider your "sudo chmod <arbitrary file>"... What if that arbitrary file is/or contains '`rm -rf /`'..... When that gets evaluated it will be reprocessed... with privileges. |
Quote:
And there are no perfect solutions to anything like this. There will ALWAYS be holes, as long as there are users. At least in this case, they can only run one shell script, and since it's preceded by sudo, the exact string/command will be logged. If someone does something wrong, it'll be VERY easy to spot, which will be a deterrent. And, if that user can't be trusted with sudo rights, they shouldn't be able to run anything as sudo. There's also a bit of security-through-obfuscation, since the user won't know what's in that shell script, what it looks for/logs, or how it works. Just that it DOES. |
None of that is relevant if the user account gets compromised.
BTW, it is nearly impossible to get a shell script to validate strings properly... |
Quote:
As far as I know, there ARE no perfect solutions to security, other than locking your computer in a bank-vault, that only YOU can open, and never connecting it to a network or running any software that you, yourself didn't write. And if a user account gets compromised, you have problems anyway, no matter which account it is. |
All times are GMT -5. The time now is 12:58 PM. |