Subject: [netatalk-admins] netatalk and group file permissions

From: Ken Weiss <[email-masked]>
Date: Fri, 2 Jul 1999 11:27:51 -0700

I noticed something interesting... I have a directory on my server that I
shared out through the AppleVolumes.default file. This directory is owned
by root, group ownership is cdlstaff. Permissions for the directory are 775
- read/write for both owner and group, read-only for others. Authenticated
users coming in with a GID other than cdlstaff can still write files to
this directory thorough netatalk:

# ls -l /var/data
total 1
drwxrwxr-x   4 root     cdlstaff     1024 Jul  2 09:40 public

# ls -l /var/data/public
total 75
-rw-rw-r--   1 kweiss   users       57314 Jun  5 13:22 deck
-rw-rw-r--   1 kweiss   users       16896 Jun  5 13:20 deck estimate
-rw-r--r--   1 kweiss   cdlstaff        0 Jul  2 09:28 foo

See? Even though the permissions on the directory shouldn't permit it (and
don't permit it from the Linux command line), Netatalk is creating files
there with group ownership of 'users.' How come?

I'm running netatalk-1.4b2+asun2.1.3 on a freshly minted RedHat 6.0 system
(Linux myhost.domain 2.2.5-15smp #1 SMP Mon Apr 19 22:43:28 EDT 1999 i686
unknown).

--Ken

-------------------------------------------------------------------------
Ken Weiss                                              [email-masked]
California Digital Library Technologies            (510) 710-3356 (voice)
UC Office of the President                           (510) 763-2471 (fax)
1111 Franklin Street #7313B          [email-masked] (text page)
Oakland, CA  94607-5200              http://dcas.ucdavis.edu/kenhome.html

---

From: Ken Weiss <[email-masked]>
Date: Fri, 2 Jul 1999 15:53:14 -0700

At 5:33 PM -0500 7/2/99, Buck Huppmann wrote:
>If kweiss doesn't belong to group cdlstaff, of course, then I'm a
>fool for going off on this flight of pedantry, if not for using the
>word pedantry

Well kweiss certainly does belong to cdlstaff, so you're no fool on that
account. But the process fsgid assigned by netatalk to the instance spawned
for kweiss is not cdlstaff. So, as far as my limited understanding goes,
the process shouldn't have write permission to the directory, because the
process doesn't belong to cdlstaff (even though kweiss does).

>From the ownership of /var/data/public/foo, it seems that kweiss (you?)
>might belong to group cdlstaff. If that's the case, kweiss (or neta-
>talk running as kweiss--same thing, almost) has permission to create
>stuff in /var/data/public of whatever sort he wants to (almost),
>with whatever permissions he wants; the file's group ownership is de-
>termined by the kernel initially. In the case of Linux, ownership is
>determined at creation time as spelled out in this excerpt from the
>mount(8) man page (at least for ext2fs filesystems, and insofar as
>this man page is up to date)

>Since netatalk sets its effective uid to you and its gid to your primary
>gid, it will create stuff owned by your primary group. If this isn't
>what you want, you (or root) can set the setgid bit on your directories
>(which is inherited by subdirectories created subsequent to such setting)
>

This all makes sense, and kweiss is a member of cdlstaff. However, when
netatalk logs kweiss in, the GID assigned is 100, which is the default
group in that passwd file, not the cdlstaff group. If I go to that
directory at the Linux command line and attempt to write files, I get
'Permission denied' until I do a 'newgrp cdlstaff'. Then I can write files.
That's exactly the behavior I expect.

Netatalk appears to be able to write to any directory where I might
conceivably have access as a group member, even if it is not the primary
group that Netatalk obtains from the passwd file. I understand perfectly
why the GID on the files netatalk creates match my default GID. That's the
fsgid of the current process. However, that fsgid should not have
permission to write into that directory. I don't understand why netatalk
allows me to write into that directory in the first place, since my primary
group does not have write permissions there. It seems like Netatalk
automatically does a newgrp for every possible group I might belong to.

As for using the word pedantry... :-)

--Ken

---

From: Tim Carlson <[email-masked]>
Date: Fri, 2 Jul 1999 20:38:10 -0600 (MDT)

> That's exactly the behavior I expect.

You shouldn't.. If you are a member of the group, regardless of whether it
is your primary group, you should be able to write files into that
directory. And IMHO you shouldn't have to be doing this newgrp garbage.
That is what "chmod g+s" is for

I would say that Linux is broken if this is how it does things.. Like what
if you want to ftp something into a directory that is 775 for a certain
group that you belong to but it isn't your primary group. Shouldn't you be
able to write files to that directory?

SunOS and Solaris have the behavior *I* would expect, but of course that
is my primary background..  Are there any other OSes out there that
exhibit this behavior of having to do a chgrp?  Or do I just lead a
sheltered life :)  NextStep is also like I would expect. 

Tim

Tim Carlson                                  Voice:    (505) 984-8800x255
Director of Computing: Santa Fe Institute    Fax:      (505) 982-0565
WWW: http://www.santafe.edu/~tim             Email:   [email-masked]

---

From: Buck Huppmann <[email-masked]>
Date: Fri, 2 Jul 1999 17:33:23 -0500

grpid or bsdgroups / nogrpid or sysvgroups
              These  options define what group id a newly created
              file gets.  When grpid is set, it takes  the  group
              id  of the directory in which it is created; other-
              wise (the default) it takes the fsgid of  the  cur-
              rent  process,  unless the directory has the setgid
              bit set, in which case it takes the  gid  from  the
              parent  directory, and also gets the setgid bit set
              if it is a directory itself.

buck