#660 3.1.12: incoherent handling of groups

[Seegras]

(Copy-paste from X11 primary buffer is apparently broken on sourceforge. grrrr. Anyway):

This user "person" is, apart from being in the default group "users" also in the auxiliary group "cc". She is not in the group "aa":

# grep person /etc/group
team:x:1001:person
cc:x:1056:person

# grep :100: /etc/group
users:x:100:

# grep person /etc/passwd
person:x:1135:100:Test Person:/home/person:/bin/bash

With this group cc, she has read-only access to the main share, and read-write to a subdirectory of this share:

[Share]
    path = /share
    valid users = @aa,@cc
    directory perm = 0770
    file perm = 0660
    umask = 5007
    rolist = @cc

[CC]
    path = /share/cc
    valid users = @cc
    directory perm = 0770
    file perm = 0660
    umask = 5000

If she uploads to the share cc where she has write-access, this here can happen:

# ls /share/cc
drwxrwsrwx  9 person    users 4096 Apr 20 08:35 200304
drwxrwsr-x  3 person    cc    4096 Apr 20 10:37 200415

Yes, these are two directory she uploaded today.

Which group and umask will be used is completely unpredictable.

Version of netatalk is 3.1.12~ds3 from Debian/Stable.

Expexted behaviour: deterministic

Hoped for solution: Method to set a group-id for each share that will be used for setting the file permissions.

[Daniel Markstedt]

FWIW I don't think it's a good practice to have both a dir and a subdir to that dir defined as shared volumes. I think they should be kept nested separately. Do you have a real-life usecase where you actually want to nest them like this?

That said, a more deterministic behavior on netatalk's behalf is definitely preferable.