XPost: comp.unix.internals, comp.unix.questions, comp.unix.shell   
   From: urs@isnogud.escape.de   
      
   Bruce Barnett  writes:   
      
   > Each file has a user ID and group ID associated with it.   
   > The system:   
   >         checks the user ID of the person, and the file.   
   >         If the number is the same, then permission is granted.   
      
   No, it depends on the user's permissions on the file.   
      
   > OTHERWISE   
   >         The list of groups of the user is obtained, and if one of them   
   matches   
   >         the group of the file, permission is granted.   
      
   No, it depends on the group's permissions on the file.   
      
   > OTHERWISE   
   >         The "other" permission is used.   
   >   
   >   
   > So if you have  the following permissions (userID = 100, group ID == 200)   
   >         User   Group    Other   
   >         RWX    ---      R   
   >   
   >   
   > User ID 	Group ID			Permission   
   > 100         (doesn't matter)    RWX   
   > 150         (200)               None   
   > 151         151                 R   
   >   
   > Note that the "other" permission is used if UID != 100 AND GID != 200   
   > If the GID matches, then "other" is never checked.   
      
   Your description above is quite inaccurate.  What matters is "the user   
   ID of the person" but the effective user ID of the process, and also   
   not "the list of groups of the user" as found in /etc/passwd and   
   /etc/groups but the effective group ID and the supplementary groups of   
   the process.   
      
   A more accurate description is:   
      
   Each file (regular file, directory, char or block special device file,   
   etc.) has in its inode a user ID, a group ID, and 9 bits of   
   permissions, i.e. 3 bits corresponding to the user ID, 3 bits   
   corresponding to the group ID and 3 bits for "others".   
      
   Each process has (besides further attributes) an effective user ID, an   
   effective group ID, and a list of supplementary group IDs (typically   
   limited to 16 or 32 IDs).   
      
   1. If the effective user ID of the process if 0, access is granted.   
      
   2. Otherwise, if the user ID of the file matches the effective user ID   
      of the process, the 3 permission bits corresponding to the user ID   
      are checked.   
      
   3. Otherwise, if the group ID of the file matches the effective group   
      ID of the process or one of the list of supplementary group ID, the   
      3 permission bits corresponding to the group ID are checked.   
      
   4. Otherwise, the 3 permission bits for "other" are checked.   
      
   Many modern Unices and Unix file systems have more complex rules for   
   checking access to files.  Instead of allowing everything toe root,   
   i.e. processes with effective uid 0, some systems know POSIX   
   capabilities, so processes can have the several capabilities of file   
   access operations, the capability to set the uid and gid, the   
   capability to send signals, etc.  Modern file systems support access   
   control lists (ACL) that allow you specify different file access   
   permissions for a number of users and/or groups.   
      
   Followup set to comp.unix.questions, since this is OT in all of the   
   other groups.   
      
   urs   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)