Originally Posted by vit_r
Here it goes according to 'ls': dr-x..
~ # ls -ld /proc
dr-xr-xr-x 134 root root 0 2010-08-13 18:58 /proc/
---------- /proc/ is not writable. So next is correct
~ # touch /proc/rwtest
touch «/proc/rwtest»: No such file or directory
Here it does not (obviously next is correct for OS functioning)..
~ # ls -ld /sys
drwxr-xr-x 134 root root 0 2010-08-13 18:58 /sys/
---------- /sys/ is writable!
~ # touch /sys/rwtest
touch «/sys/rwtest»: No such file or directory
First thing, /sys and /proc are not real fs's, they represent internal structures taken directly from your kernel mapped memory and put in an fs-like fashion, so most Linux programs that know how to handle files can take info from there just like they would get info from ~/my_random_txt_file. Note that these files don't even exist, not even in a ram disk or something like that.
The reality is that everything under /proc is created on demand. So, even if you could chmod a file in there, the next time you run ls to see that file you would not be viewing the same file you chmoded, but a new one that's created on the very momment that ls asks for it to the kernel. The kernel procfs driver is the one that does this transparently.
Besides that, you are not supposed to write in there at except for a few cases, and only when you know what you are doing.
In any case, even if /proc was a true fs which it is not, you shouldn't be that scared about this. Attributes have always been fs-dependant, take vfat as an example. It doesn't support posix permissions, and all the umask stuff is emulated at mount time, and never stored. Other virtual fs's (nfs, smb, cifs, fuse based stuff...) have their own rules to emulate and handle permissions and ownerships which might also be controlled via mount options.
Why does 'chmod 500..' not work under root privileges?
Thanks and good luck!
Try on a conventional POSIX friendly fs
instead of doing weird things on virtual fs's.
Originally Posted by vit_r
Certainly this help
> root user can read,write & delete files even if it has read or no permission.
Is it said somewhere in docs? I can't find
It's only natural. What would happen then if you -by accident- did a chmod a-r on a given file? If root couldn't read it who would rescue this file from limbo? Maybe debugfs, but that's suboptimal at best.
Root can do anything, and has absolute rights over ALL the files in your system. Only limited by what the kernel allows or disallows.
Seems strange things pops up:
- 'ls' doesn't reflect 100% of real situation
- 'chmod ...' doesn't make all changes correctly
Sure they do. These tools do what the kernel let them do, and don't forget that this tools are not exclusively used over Linux kernels. ls can only show what the fs driver tells it. That might depend from one mount of the fs to another because some attributes on some fs's are controlled by such options as said above.
To sum up. That a given file has a given permission scheme doesn't really allow you to do whatever thing with it. There are additional levels to consider, for example, just pick a floppy 3.5" disk and open the protection latch, put it in your drive and look for a writable file, try to write to it and you'll see you can't. In this case the obstacle is the physical level, but the kernel is also above what chmod and ls can do.
- nothing is mentioned in their man pages
Because this has nothing to do with chomd and/or ls. This is kernel internal stuff.
You should also check Documentation/filesystems/proc.txt and Documentation/filesystems/sysfs.txt in your kernel source tree to get a clearer view on what do these fs's do.