LinuxQuestions.org - disabling command

- Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)

- - disabling command (https://www.linuxquestions.org/questions/linux-newbie-8/disabling-command-751965/)

disabling command

Hi,

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.

mudit

well you have several ways to do that:

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.

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.

Quote:

Originally Posted by b0uncer (Post 3666948)

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.

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

mudit

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.

yes, I agree with lazlow, I guess it is better to make individual users but in 1 global group something like:

user1:coders
user2:coders
user3:coders

If user1 makes something that you did not approve then you can know that HE did it and nobody else.

Then in sudoers you can restrict the use of rm, dd, mv, shred...etc to the whole group

Quote:

Originally Posted by muditcse@yahoo.com (Post 3667816)

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.