I thought I understood Unix filesystem permissions

I’ve been using ’nix operating systems (mostly Linux distributions) since my freshman year of college. I’m mostly self-taught, fair enough, but there was an appreciable quantity of ’nix in my coursework as well. I’ve worked in HPC since 2006. I use Apple OS X as a primary desktop OS because it’s a BSD that I don’t have to get working myself.

With this in mind, imagine my embarrassment to today discover a fundamental misunderstanding of ’nix filesystem permissions.

We, at the KAUST supercomputing laboratory, use a central LDAP directory for authentication and authorization. Predominately Linux hosts use a combination (not necessarily all at the same time) of nss, pam, and sssd to communicate with this directory.

Way back in time immemorial, a coworker designed a series of scripts for doing basic CRUD operations; e.g., create an account. This solution not only creates a posixAccount object, but also creates a posixGroup object. This group has a cn equal to the posixAccount’s uid, and a gidNumber equal to the posixAccount’s uidNumber. This posixGroup is used as the primary group for that account: it’s gidNumber is stored in the posixAccount’s gidNumber. The intent here is both to simplify management of “project groups” such that none of them are used as the user’s primary group and to protect user files from other accounts on the system.

For reasons based mostly in my own compulsive desire for neatness, we decided to eliminate these user-private groups in favor of the universal primary gid “100” (or “users”). The CRUD script was updated accordingly, and the long task of updating the existing filesystem began:

find /gpfs \( ${long_series_of_groups} \) \( \
    \( ! -type l -exec chmod g-rwx {} \; \) , \
    -exec chown -h :100 {} \; \)

The intent here is to chown any file currently owned by a user-private group to the new users group, and to chmod group rights from such files (since effectively no group rights were granted, given the ownership by a user-private group).

I was met with surprise when access was later denied to such files.

Apparently, ’nix filesystem permissions are disjointed. Access by the file owner is only mediated by the owner bits; access by group members (other than the owner) is defined only by the group bits; and the other bits only apply to users that are not in the first two categories. This means that a file like testfile:

-rw----r-- 1 root users 0 2011-07-03 07:38 testfile

is not readable by members of the users group, even though the r bit is set in the lowest order.

It seems that, rather than chmod g-rwx, I should have copied group permissions from the “others” access rights.


A coworker has advised that I post the find command that I’m using to fix this. Apparently using multiple -execs is convoluted or something.

find $fs -group users ! -type l \( \
    \( -perm -o+r -exec chmod g+r {} \; \) , \
    \( -perm -o+w -exec chmod g+w {} \; \) , \
    \( -perm -o+x -exec chmod g+x {} \; \) \)