first octet of chmod does not work?
 

Hi!

I.
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
~ #

II.
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
~ #

III.
~ # mkdir TMP
~ # chmod 500 TMP
~ # ls -ld TMP
dr-x------ 2 root root 48 2010-08-13 18:59 TMP/
~ # touch TMP/rwtest
~ # ls -lR TMP
TMP:
-rw-r--r-- 1 root root 0 2010-08-13 18:59 rwtest
~ #

rwtest-file was created by root in directory with dr-x------

Should it be so?

Please..
One question only:

Why does 'chmod 500..' not work under root privileges?

Thanks and good luck!

13-VIII-2010

Chmod 500 does not work under root privileges as UIDs starting with 500 are reserved for user access & to provide root access to users, SUID & sudo commands are used.

Thanks

Also that is depended on your umask value which is set for the directory thats why you are getting the above comment as "dr-x------ 2 root root 48 2010-08-13 18:59 TMP".
Your umask value is not set as per directory access for users.

to smilemukul

Thanks for digging notes

I had to mention what its for, sorry..

The goal is to get 'read-only PATH'
(
ie:
dr-xr-xr-x ... bin/
dr-xr-xr-x ... lib/
dr-xr-xr-x ... sbin/
)

-
Still does not work:
~ # umask u=,g=,o=; mkdir fu; touch fu/bar; ls -lR fu
fu:
---------- 1 root root 0 2010-08-14 13:00 bar
-

'ro PATH' whith rw root filesystem is possible:
http://www.linuxquestions.org/questi...y-path-822055/

But when under root privileges 'chmod 500..' will do what it claims 'ro PATH' would be made just like that, isn't so?

Is there a way to get working 'dr-xr-xr-x..' directly?

Thanks

To discover what umask you are currently working with, type:
% umask

EXAMPLES --
umask directory file
000 rwxrwxrwx rw-rw-rw-
022 rwxr-xr-x rw-r--r--
027 rwxr-x--- rw-r-----
077 rwx------ rw-------
777 --------- ---------

Check your umask value & search more about it on the google.

-
Once more:
~ # umask
0022
~ # umask u=,g=,o=
~ # umask
0777
~ # mkdir fu
~ # ls -ld fu
d--------- ... fu/
Next cmd in unwritable dir certainly should fail
~ # touch fu/bar
But it didn't fail: fu/bar was created.
Look:
~ # ls -l fu/bar
---------- ... bar
~ # umask 0022
~ # umask
0022
-

Still does not work:
Is there somewhere a working example?

Thanks

/proc and /sys is a virtual filesystem.

/sys directory for PnP configuration. It's a sysfs type of file system.

quote from wiki
root user can read,write & delete files even if it has read or no permission.

try this

Hope this help.

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

Seems strange things pops up:
- 'ls' doesn't reflect 100% of real situation
- 'chmod ...' doesn't make all changes correctly
- nothing is mentioned in their man pages

To whom to address these questions to get the "official" answers?


Thanks

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.

Try on a conventional POSIX friendly fs instead of doing weird things on virtual fs's.

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.

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.

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.

to i92guboj


Thanks for detailed analysis and good hints

I had to be more accurate when posting


> ... doing weird things on virtual fs's.
There was no such intention. '~ # ls -ld /proc' and '~ # ls -ld /sys' were invented
to illustrate their different output: dr-x.., drwx..
while they both are not writable.

All these.. still puzzles me.. may kernel-team can be asked?