chmod restrictions

Latest response

I'm not too sure if this topic has already been discussed, if it has, I apologize. If there is already a fix or restriction for the type of issue below, please let me know, but would be nice to have some sort of restriction in RHEL 7.

 

When logged in as root (I know best practices dictate not to log in as root but as a power user instead, but it will happen), when running the chmod command in the following way: "chmod -R 777 /" this will have drastic effects on the machine. Is there a possibility of preventing this particular command from running within the kernal? or at least an "ARE YOU DEFINETLY SURE YOU WISH TO DO THIS?!?!" question

 

If you google this, you'll find that I'm not the only one that's had this issue.

 

Thanks to all who take the time to read and respond :)

Responses

chmod does not have an interactive option, like rm does. If you execute 'rm -R /' you should get an interactive dialog for each deletion because rm is usually aliased to rm -i. But chmod does not have that functionality so I don't think this is a RHEL 7 issue but a request to add an interactive option to chmod.

 

I also have to point out that many utilities do not have an interactive option, and thus need to be used extremely carefully. Yes, you should use sudo and not just su up to root and go to town.Also I've never met anyone who has issued a recursive chmod 777 over the root...if you were having everyone use sudo this would/could be caught in an audit log.

 

So in conclusion, a) chmod would need an interactive option and b) no one should be issuing commands like this as root. And those with sudo should be system admins who know better than to issue a command like that.

 

I'm not sure who/where you'd request a chmod interactive option though. GNU perhaps?

A recursive chmod is just one of many things that can cause temporary or permanent harm to a host.

It can be (mostly) corrected with a shell script to do a recursive 'rpm --setperms'.

I'd be more concerned with things like users running mkfs or a recursive rm on production hosts.

Here's a good article on RPM and permission/ownership correction:
http://www.cyberciti.biz/tips/reset-rhel-centos-fedora-package-file-permission.html

As sysadmin you have a big shutgun that can cause lots of damage and adding "-i" may feel good but can backfire badly.

One friend who had "alias rm=rm -i" ended up wiping way more then intended when he - being used to always have to confirm deletes - did something like "rm *" and just got the prompt back with no chance to say "no" to a few files he planned to keep.

I don't see anyone doing "chmod -R 777  /" but what I have seen is a small install script like
 cd /
 chmod -R ug+rwX someapp
 cd someapp
 chown -R app:grp *
and after that script nothing worked because /someapp didn't exist and every file on the server was no owned by app:grp (remember SUID = set owner, not set root so chown also failed).

 

If going by the original part of the op, verify when doing dangerous things - it is not that easy to know when to block a specific command since there are so many commands that will hose your system. If the kernel somehow would decide that "chmod -R 777 /" should be blocked then what about "dd if=/dev/zero of=/dev/sda bs=1M" which I purposly run now and then to wipe a decommed system.
After all, this is unix and if you are root you have to freedom to do whatever you want, and want to shoot your self in your foot it is your right to be able to do that.

/ps