Re: Mailbox locking

[vp@example.com (Viktor Pavlenko)]

Thank you for reply. At least sgid+x is clear. As for sgid-x
/usr/src/linux/Documentation/mandatory.txt on my RH7 system reads:

>A file is marked as a candidate for mandatory locking by setting
>the group-id bit in its file mode but removing the group-execute
>bit. This is an otherwise meaningless combination, and was chosen
>by the System V implementors so as not to break existing user programs.

And... yes I have to read some man/info pages before typing any
more:)

Viktor


>>>>>> "Viktor" == Viktor Pavlenko <vp@example.com> writes:
>
>    Viktor> Can anyone shed some light on s (=sgid+x) and S (=sgid-x)
>    Viktor> things?
>
>becomes the gid of the owner"???
>
>suid = Set User ID.  This means the effective user of the process is
>set to the owner of the executable file, and the process has the same
>permissions that the file owner has for the purpose of checking the
>user mode.
>
>sgid = Set Group ID.  Same as suid except substitute group for owner.
>
>These are pretty meaningless if x is not set, but for orthogonality's
>sake you can do chmod 2666 file if ya really wanna.
>
>On some systems, you can do chmod 1nnn.  This is called the "sticky"
>bit, and that is the one that calls for mandatory locking.
>
>When these are directories, they have different meanings.  An "suid"
>directory is meaningless (IIRC), an sgid directory means "use my
>permissions as default when you create children in me", and a
>directory with the sticky bit set restricts certain directory
>manipulations to the owner of the directory or file.
>
>Look up stat(2).  (No, chmod(2) isn't a lot of help, and chmod(1) is
>only a little bit more.  ;-)
>
>Info may be better than man.