Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I want that no user (ofcourse other than root) be able to run 'rm -rf' command on my server.How to make entry for this in sudoers or tell me the other method.
1) you can create an alias for the rm -rf command which executes nothing.
2) you can actually create a dummy script and replace rm (in which case you should rename rm to something else so YOU can use it?)
3) if you dont want them to delete a specific folder and/or its contents then try the sticky bit... like this: chmod 1755 dir/ (the 1 makes it that people can write in that folder but cannot delete what does not belong to their user:group, so they wont be able to delete what other user or groups have created in that folder except for root of course, the folder /tmp is a perfect example of that)
from wikipedia:
Quote:
"The most common use of the sticky bit today is on directories, where, when set, items inside the directory can be renamed or deleted only by the item's owner, the directory's owner, or the superuser; without the sticky bit set, any user with write and execute permissions for the directory can rename or delete contained files, regardless of owner. Typically this is set on the /tmp directory to prevent ordinary users from deleting or moving other users' files. This feature was introduced in 4.3BSD in 1986 and today it is found in most modern Unix systems.
The sticky bit can be set using the chmod command and can be set using its octal mode 1000 or by its symbol t (s is already used by the setuid bit). For example, to add the bit on the directory /usr/local/tmp, one would type chmod +t /usr/local/tmp. Or, to make sure that directory has standard tmp permissions, one could also type chmod 1777 /usr/local/tmp.
In Unix symbolic file system permission notation, the sticky bit is represented by the letter t in the final character-place. For instance, on Solaris 8, the /tmp directory, which by default has the sticky-bit set, shows up as:
Code:
$ ls -ld /tmp
drwxrwxrwt 4 root sys 485 Nov 10 06:01 /tmp
If the sticky-bit is set on a file or directory without the execution bit set for the others category (non-user-owner and non-group-owner), it is indicated with a capital T:
Code:
# ls -l test
-rw-r--r-- 1 root other 0 Nov 10 12:57 test
# chmod +t test; ls -l test
-rw-r--r-T 1 root other 0 Nov 10 12:57 test
"
And anything else that you can think of along those lines.
--
if the questions help you please press the thank button below. =)
There another possibility too. It doesn't prevent users from running "rm -fr", but prevent deleting the whole disk: I haven't tried it myself, but I guess it should work:
Assumin you have ordinary users on your system, they will have to run "sudo" to delete files that they don't own themselves. Then you can modify /etc/sudoers to prevent users from running "rm -fr".
There is another possibility but do it on your own risk. rm command resides in /bin and has read and execute permissions for others. It is owned by root. Remove the permissions for others. BUT do it on your own risk though you can change the permissions later on.
Distribution: Debian squeeze (Gnome) on netbooks; Debian Lenny on servers and Debian wheezy (XFCE) on new laptops
Posts: 144
Rep:
With all do respect, I think in all cases sudoers still can omit the blocking of the command because root can still do an rm -rf. You also have to block the sudo su - command to prevent sudoers becoming root.
If there are several users on the system (especially then), sudo should be configured so that only certain commands (those that are really needed) can be run using sudo and nothing else. The typical approach that some users cannot use sudo at all and some can run whatever they want is bad, because it's the equivalent of having several users with root privileges in addition to those who are only ordinary users. So remove all access to sudo except for those specific commands you want those other people to run.
If you're trying to prevent people from breaking up your system, "disabling" rm is not enough (and people should still be able to use it -- it's essential). Think about what they can do with dd, mv and shred for example.
If you're trying to prevent people from breaking up your system, "disabling" rm is not enough (and people should still be able to use it -- it's essential). Think about what they can do with dd, mv and shred for example.
Actually a valid point... shred, dd and mv are very powerful ways to delete files beside rm -rf.
In my opinion, and unless you users are really novice, this is a waste of time.
Aliases can by bypassed by escaping the command with \, and in addition there are shells that have rm as a builtin, like busybox. You probably have busybox installed, and if the system-wide rm is not fully functional, they will soon find that an alias rm='busybox rm' is their best friend. Even if it's not installed by default (which would be rare nowadays) the user can always install and use his/her own shell. And if there's no compiler, a binary rpm can be used, then they can spawn their own shell and use that instead of yours.
No user is going to stand writing 'y' 100 times to erase a folder. And anyway, they can do that in a graphical filemanager, or just do "yes | rm *", there's really not much point in trying to limit that. Anyway, it's their own stuff which they will screw if they do something wrong.
Allowing more than one user to use the same username is a good way to get into trouble in a hurry. One (of the many) advantages to having one account per users is that you can hold those users accountable for their specific actions. When people know that their actions can be tracked back to them specifically they are much more careful about what they do (far fewer issues to deal with). This also allows you to split the users into different groups with different privileges for each group.
hi all,
thanks for reply.
1)No stickty bit...since all users belogs to same group and also username is same...
Actually there is a CVS directory on my server and i want no user can run rm -rf on that server.I think sudo will be best...
give your views please,,,
regards.
mudit
bit of a long shot, but have you tried the chattr command?
Code:
man chattr
There are various options that may or may not work in your situation mainly the -u -i and -a flags. The -u flag which is best suited to your situation does not work on ext2/ext3 filesystems though.
Give the man page a good read to determine if it helps you or not.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.