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


Subject: Re: [netatalk-admins] netatalk and group file permissions
From: Buck Huppmann (Charles-Huppmann@UIowa.edu)
Date: Fri Jul 02 1999 - 18:33:23 EDT


On Fri, Jul 02, 1999 at 11:27:51AM -0700, Ken Weiss wrote:
> 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?

>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)

       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.

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)

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

buck



This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:54 EST