I've had a strange problem occurring lately - after a reboot my home folder's contents aren't shown in nautilus or thunar, and ls -a hangs when ran as a user. ls -a runs correctly and shows all the files when ran as root. I have checked the folder and file permissions for the folder and they are all normal - Create and Delete access for my user. Sometimes a reboot will fix the issue. Very irritating bug.
Running F13 Beta.
Thanks.
On Fri, 2010-04-23 at 01:37 -0500, John H wrote:
I've had a strange problem occurring lately - after a reboot my home folder's contents aren't shown in nautilus or thunar, and ls -a hangs when ran as a user. ls -a runs correctly and shows all the files when ran as root. I have checked the folder and file permissions for the folder and they are all normal - Create and Delete access for my user. Sometimes a reboot will fix the issue. Very irritating bug.
You need Execute permission for directories to be able to look up files in them. And Read permission to be able to list them. Typically a home directory should be 0755.
poc
Hi Patrick,
On Friday 23 April 2010 07:54 AM, Patrick O'Callaghan wrote:
You need Execute permission for directories to be able to look up files in them. And Read permission to be able to list them. Typically a home directory should be 0755.
I have never properly understood the leading bit in permissions. (the 0 in the 0755) Could you point me to some easily understandable resource?
poc
Once upon a time, Suvayu Ali fatkasuvayu+linux@gmail.com said:
I have never properly understood the leading bit in permissions. (the 0 in the 0755) Could you point me to some easily understandable resource?
The leading 3 bits is essentially an add-on to each of the user, group, and other sections. For user and group, the corresponding bit is the set-id bit. For executable filess with the set-user-id bit (e.g. 4xxx) or set-group-id bit (e.g. 2xxx) set, the executable runs as the files owner or group, not the calling user or group.
For directories, set-group-id means that new entries in that directory inherit the group from the directory instead of the calling group.
The bit corresponding to other (e.g. 1xxx) is called the "sticky" bit. On directories (such as /tmp), it means that only users/groups with permissions to a file can delete it.
In old Unix, the sticky bit on an executable changed the way the kernel paged it into and out of RAM, but I don't believe Linux uses it.
On Fri, 2010-04-23 at 10:52 -0500, Chris Adams wrote:
In old Unix, the sticky bit on an executable changed the way the kernel paged it into and out of RAM, but I don't believe Linux uses it.
Actually it meant the "text" segment (code and constant data) was write-protected during execution, and hence could be shared between multiple processes executing the same program. In fact that's why it was called the "sticky" bit -- the text segment could stick in RAM even if the process was swapped out, and in fact never needed to be swapped out because it could always be reloaded from the executable file. This is now assumed in the case of modern paging systems, but in the old PDP-11 it wasn't available on all models and could in some corner cases reduce the total amount of virtual memory available to the process (you only had a total of 8 physical segments of up to 32Kb each, and the stack took up at least 1; later models allowed 16 segments total but 8 could only be text and 8 could only be data or stack). Hence it had to be user-modifiable.
Now I'm showing my age :-)
poc
Actually it meant the "text" segment (code and constant data) was write-protected during execution, and hence could be shared between multiple processes executing the same program. In fact that's why it was called the "sticky" bit -- the text segment could stick in RAM even if the process was swapped out, and in fact never needed to be swapped out because it could always be reloaded from the executable file. This is now assumed in the case of modern paging systems, but in the old PDP-11 it wasn't available on all models and could in some corner cases reduce the total amount of virtual memory available to the process (you only had a total of 8 physical segments of up to 32Kb each, and the stack took up at least 1; later models allowed 16 segments total but 8 could only be text and 8 could only be data or stack). Hence it had to be user-modifiable.
[although you needed a later 2.x BSD to utilise anything beyond 64K code 64K data. 2BSD could do segment handling stuff [think DOS EMS and try not to get flashbacks from the horror]
Now I'm showing my age :-)
The V7 manual doesn't quite agree with you. The sticky bit simply indicates that the code segment for the binary should be kept around in memory/swap (fast storage) not discarded. It might get set on a tiny number of root apps to tune performance.
Anyone who remembers "resident" on the Amiga has the right idea.
It did require on the 11 that the program was split I/D so there was an unmodifiable code segment but that's an implementation detail for that architecture. Some Unixen today still honour the sticky bit for executables - but not many.
As it was only relevant for executables it also got borrowed for other bits. For directories it indicates that only the file owner can unlink(remove) files - mostly to fix /tmp. A couple of systems use it for other 'magic' on non-executable files.
Alan
On Fri, 2010-04-23 at 18:07 +0100, Alan Cox wrote:
The V7 manual doesn't quite agree with you. The sticky bit simply indicates that the code segment for the binary should be kept around in memory/swap (fast storage) not discarded. It might get set on a tiny number of root apps to tune performance.
Yes, I'd forgotten about the "keep it in swap" implications. Swap was of course always a separate partition and accessed contiguously, not via normal filesystem operations. That made reloading swapped segments faster than accessing the original file.
poc
Once upon a time, Alan Cox alan@lxorguk.ukuu.org.uk said:
The V7 manual doesn't quite agree with you. The sticky bit simply indicates that the code segment for the binary should be kept around in memory/swap (fast storage) not discarded. It might get set on a tiny number of root apps to tune performance.
The only time I remember seeing it set was on /usr/bin/emacs on a Sequent Symmetry (the wonderful world of DYNIX/ptx and choosing your "universe").
Hi,
On 23 April 2010 08:52, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, Suvayu Ali fatkasuvayu+linux@gmail.com said:
I have never properly understood the leading bit in permissions. (the 0 in the 0755) Could you point me to some easily understandable resource?
The leading 3 bits is essentially an add-on to each of the user, group, and other sections. For user and group, the corresponding bit is the set-id bit. For executable filess with the set-user-id bit (e.g. 4xxx) or set-group-id bit (e.g. 2xxx) set, the executable runs as the files owner or group, not the calling user or group.
For directories, set-group-id means that new entries in that directory inherit the group from the directory instead of the calling group.
The bit corresponding to other (e.g. 1xxx) is called the "sticky" bit. On directories (such as /tmp), it means that only users/groups with permissions to a file can delete it.
After reading your response I knew more precisely what to look for and after some searching and looking @ `info coreutils "File permissions" "Mode Structure", I think I understand them now.
However I failed to find how to see whether any of those bits are set for a file. I tried `ls -l ' in /bin, /usr/bin, and /tmp but didn't notice anything obvious. I also failed to find any appropriate option for ls to list it either. Am I looking in the wrong place?
Also in what situations would seting the setuid or setgid bits help? I could think of some, like writing configuration files for the application which are otherwise owned by someone else, maybe for a web server or a daemon or maybe some automated backup solution. Are these valid scenarios?
In old Unix, the sticky bit on an executable changed the way the kernel paged it into and out of RAM, but I don't believe Linux uses it. -- Chris Adams cmadams@hiwaay.net
Once upon a time, suvayu ali fatkasuvayu+linux@gmail.com said:
However I failed to find how to see whether any of those bits are set for a file. I tried `ls -l ' in /bin, /usr/bin, and /tmp but didn't notice anything obvious. I also failed to find any appropriate option for ls to list it either. Am I looking in the wrong place?
Run "ls -ld /tmp" and you should see:
drwxrwxrwt. 17 root root 4096 2010-04-23 14:37 /tmp
The "t" at the end (instead of a normal "x") indicates the directory sticky bit.
Also in what situations would seting the setuid or setgid bits help? I could think of some, like writing configuration files for the application which are otherwise owned by someone else, maybe for a web server or a daemon or maybe some automated backup solution. Are these valid scenarios?
You should only have setuid/setgid for programs that are designed for privilege escalation (such as /bin/su and /usr/bin/passwd). Setting them on arbitrary programs is a security problem (since you could be giving any user the ability to do random things as another user, possibly root).
On 23 April 2010 12:39, Chris Adams cmadams@hiwaay.net wrote:
Once upon a time, suvayu ali fatkasuvayu+linux@gmail.com said:
However I failed to find how to see whether any of those bits are set for a file. I tried `ls -l ' in /bin, /usr/bin, and /tmp but didn't notice anything obvious. I also failed to find any appropriate option for ls to list it either. Am I looking in the wrong place?
Run "ls -ld /tmp" and you should see:
drwxrwxrwt. 17 root root 4096 2010-04-23 14:37 /tmp
The "t" at the end (instead of a normal "x") indicates the directory sticky bit.
I was looking at the contents and not /tmp itself. :-p I also looked at /bin/su and /usr/bin/passwd, they have `-rwsr-xr-x' as permissions. :)
Also in what situations would seting the setuid or setgid bits help? I could think of some, like writing configuration files for the application which are otherwise owned by someone else, maybe for a web server or a daemon or maybe some automated backup solution. Are these valid scenarios?
You should only have setuid/setgid for programs that are designed for privilege escalation (such as /bin/su and /usr/bin/passwd). Setting them on arbitrary programs is a security problem (since you could be giving any user the ability to do random things as another user, possibly root).
Thanks for the response everyone. All doubts cleared now. :)
-- Chris Adams cmadams@hiwaay.net