4

I was wondering about the following behavior:

I have three users A, B and C. A creates a folder and changes the group ownership to C's group.

mkdir fold
chgrp C fold
chmod g+rw fold

Now I add B to the C user group by

usermod -a -G C B

and id B gives me uid=1002(B) gid=1002(B) groups=1002(B),1003(C). Trying to change the content of fold (mkdir fold/fold2 or touch fold/test) as user B, however, gives me a permission denied and only A and C can change the contents of that folder. What is the reason? If I change the gid of B to C by usermod -g C B, but this can't be the proper way right?

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
greole
  • 239

1 Answers1

4

Accessing a directory requires the execute (x) permission. The read (r) permission only lets you list the directory's contents, not access that content. The write (w) permission is useless without x.

chmod g+x fold

(For the benefit of future visitors with similar, but not identical symptoms)

In the output of id, gid is the user's primary group and groups lists all the supplementary groups as well. The primary group is the one listed in the passwd file and the supplementary groups are the ones listed in the group file.

The membership of a user in a group is only meaningful to the login system. After login, there is no relationship between users and groups. Each process, starting with the login process, has a primary user¹, a primary group, and any number of supplementary groups. Thus a change of the user and group databases only takes effect in sessions started after the change. In a nutshell: after adding a user to a group, log out and back in.

¹ Two, actually: effective and real — but I won't go into that here as it only applied to setuid/setgid programs.

Jeff Schaller
  • 67,283
  • 35
  • 116
  • 255
  • 1
    No, w on a directory means permission to change the directory, i.e., add/delete/rename file names in it. You'd need x to access the contents (files) in the directory, which is quite different. – vonbrand Jan 30 '14 at 13:49
  • 1
    Today, a process can belong to many groups simultaneously. And that "today" is older than Linux, IIRC. – vonbrand Jan 30 '14 at 13:51
  • @vonbrand Yes, all these groups are supplementary groups. The principal group is relevant for a few things, such as which group a newly-created file belongs to under SysV semantics. – Gilles 'SO- stop being evil' Jan 30 '14 at 15:45