#576 umask setting not working in 3.1.5 3.1.6

[Mazeno]

Hi,

In setting up netatalk on a couple of test servers, I discovered the umask setting in /etc/netatalk.conf is no longer working in versions 3.1.5 and 3.1.6.

I was previously using an umask = 0007 setting with version 3.1.2 and 3.1.0 successfully to deny permissions for POSIX others on new files/folders. (we want 770 on folders)

In the 3.1.5. and 3.1.6 versions of netatalk, the umask setting appears to be ignored for folders so they get o+rx permissions (775). New files appear to still respect the umask=0007, but they get g+x also, it becomes 670.

Here's the atalk.conf:
;
; Netatalk 3.x configuration file
;

[Global]
; Global server settings

; [Homes]
; basedir regex = /home

; [My AFP Volume]
; path = /path/to/volume

[Grafisk Cumulus AFP]
path = /mnt/DataTest/Grafisk_Test
valid users = ladmin @grafisk @fellestest
; use umask to block standard permissions assignments for group, and for others
; so we can control it in filesystem instead using ACLs
;file perm = 0660
umask = 0077

[Mazeno]

The umask setting doesn't not appear to work right for new files in version 3.1.0 either, the group permissions end up with the executable bit set even though I set umask=0017. Setting file perm = 0660 doen't change anything. New files end up with 770 regardless.

In my understanding I should get new files with 760 permissions. And maybe set directory perm = 0770 to ensure new folders get 770 and will be group writable.

[Rasmus Borup Hansen]

This patch appears to fix the bug.

--- etc/afpd/unix.c.orig 2014-07-15 21:07:33.000000000 +0200
+++ etc/afpd/unix.c 2014-09-23 21:03:07.109418837 +0200
@@ -229,7 +229,8 @@
LOG(log_debug, logtype_afpd, "setdirunixmode('%s', mode:%04o) {v_dperm:%04o}",
fullpathname(name), mode, vol->v_dperm);

• mode |= (vol->v_dperm | DIRBITS) & ~vol->v_umask;
• mode |= (vol->v_dperm | DIRBITS);

• mode &= ~vol->v_umask;

  if (dir_rx_set(mode)) {
  / extending right? dir first then .AppleDouble in rf_setdirmode /

[Rasmus Borup Hansen]

Now as attachment. It seems that Sourceforge tries to format the patch a little to nicely.

[Ralph Böhme]

Fix committed for 3.1.7 in [d517632b2d4ef26ea7bbd12794d1cf0709f33542].