Subject: Re: [netatalk-admins] netatalk and group file permissions
From: Buck Huppmann (Charles-Huppmann@UIowa.edu)
Date: Mon Jul 05 1999 - 16:35:39 EDT
On Mon, Jul 05, 1999 at 11:00:46AM +0100, nobroin@esoc.esa.de wrote:
> > At 5:33 PM -0500 7/2/99, Buck Huppmann wrote:
>
> > 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.
>
> and Tim Carlson replied
>
> >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.
>
> Tim Carlson further said
>
> >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..
>
Whereupon <nobroin@esoc.esa.de> said
> I've a similar background OS wise to Tim, but I'm also a big Linux user and
> Linux does the right thing as Tim would have it, and not as described by
> Buck in the first extract above. I checked this under Linux 2.0.36 and
^^^^
ouch. you misattribute. it wasn't me. i pointed to the ``bsdgroups''
option explanation in the mount(8) man pages included with the linux
distribution on this machine (redhat 6), wherein it says default
file-creation behavior is to create files with gid of the calling
process, unless bsd semantics are requested at mount time
> 2.2.1 and the behaviour is identical, as it should be. I think Buck needs
> to check his Linux box. Meanwhile, if he wants the files to be owned by
> cdlstaff, he just needs to do a chmod g+s on the directory, as I think
> others have pointed out.
Here's the kernel code excerpt from 2.0.36 (as destributed by Debian on
this other Linux box I'm using right now), from linux/fs/ext2/:
--- ialloc.c: in function struct inode * ext2_new_inode (const struct inode * dir, int mode, int * err)if (test_opt (sb, GRPID)) inode->i_gid = dir->i_gid; else if (dir->i_mode & S_ISGID) { inode->i_gid = dir->i_gid; if (S_ISDIR(mode)) mode |= S_ISGID; } else inode->i_gid = current->fsgid;
sb.c: in function static int parse_options (char * options, unsigned long * sb_block, unsigned short *resuid, unsigned short * resgid, unsigned long * mount_options)
else if (!strcmp (this_char, "grpid") || !strcmp (this_char, "bsdgroups")) set_opt (*mount_options, GRPID); else if (!strcmp (this_char, "nogrpid") || !strcmp (this_char, "sysvgroups")) clear_opt (*mount_options, GRPID); ---
So if you mount the device without electing options along these lines you *should* get inodes created with inode->i_gid == current->fs_gid, unless the directory is SGID. (As best i can tell, a call to open() will not change the current->fsgid; rather, in_group_p() is called with the gid of the inode of the directory into which a write is being attempted; viz., from linux/kernel/
--- sys.c: int in_group_p(gid_t grp) { int i;
if (grp == current->fsgid) return 1;
for (i = 0; i < NGROUPS; i++) { if (current->groups[i] == NOGROUP) break; if (current->groups[i] == grp) return 1; } return 0; } ---
and permission is granted if this returns true.)
With the BSD ``semantics'', inode->i_gid == dir->i_gid
As far as the comparative virtues of other *n*xes in this regard, SunOS 4 has the same mounting hack support. (See open(2).) FWIW, OTOH, for OpenBSD 2.5 the open(2) man page says the following:
When a new file is created it is given the group of the directory which contains it.
Kernel excerpts omitted b/c I'm already way out on a limb as far as stretching my understanding of *n*x/programming and b/c the last thing I want to do is run afoul of the intellectual property rights of the Regents of the University of California, having already abused the Linux kernel hackers' and this message being a follow-up to a message from someone in the upper echelons of the UC system
As for said someone's problem getting his shell to write into a directory with ownership different from his process {e,fs}gid, . . . Is there some evil program calling setgroups() before execve-ing your shell? Or does your login program not call initgroups() ? I'm afraid that this one's a mystery to me. Anybody?
As for the netatalk code itself, the only set[re]*uid() call it makes are in netatalk/etc/afp/auth.c at initial login, as far as i can tell, so I don't think it's making any heroic efforts to waylay your direc- tory hierarchies' ownerships
buck
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:16:54 EST