preeti malakar wrote: > Why is the immutable bit of all system binaries viz files in /sbin, /bin, /usr > not set, so that none can change or delete them? > > as you can see chattr /bin/login will give > ------------- /bin/login As Paul said, that would stop yum and rpm from upgrading those programs (say if the immutable binary has a security bug). Most of them are owned by root: other users can't change them anyway, due to file permissions. And root has the ability to remove the immutable bit. Yes, yum could be modified to automatically unset the immutable bit, upgrade, and then re-set it. But there's an implicit understanding that normal programs *won't* play with the immutable bit (it's not there on all filesystems, and I understand Posix[1] doesn't specify it.[2]) In any case, having yum or rpm fiddle with the immutable bit prevents the sysadmin from saying "I know what I'm doing: RPM replaces this file on ugrade, and I Want It Staying Just As *I* Edited It, ----it!" It's actually of some use as it is at the moment (as a way of over-riding the system tools). If it was treated the way you suggest, it would simply be a redundant way of expressing file permissions. Hope this helps, James. [1] Posix is the IEEE standard defining Unix-like operating systems. In practice, not every Unix-like OS is Posix-compliant, nor is every de-facto standard a part of Posix. But deliberately using something that isn't in Posix is a good way to get non-portable programs. [2] e.g. http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/files.html http://www.linuxsecurity.com/docs/LDP/Secure-Programs-HOWTO/files.html -- E-mail address: james | Examiner: How does an AC motor start? @westexe.demon.co.uk | Student: vrrrrrrrrrrRrRRRRRRR... | Examiner: Stop! Stop! | Student: RRRRRRRmmmmm.