Re: FW: Re: [netatalk-admins] permissions


Subject: Re: FW: Re: [netatalk-admins] permissions
From: Julian Elischer (julian@whistle.com)
Date: Tue Jan 12 1999 - 02:01:50 EST


What does setting the SetBGID bit of a directory achieve?
On FreeBSD that behaviour is defualt.. you don't need to set it.

On Mon, 11 Jan 1999, Mark J. Taylor wrote:

>
> Hi!
>
>
> Following is an old email (May 6, '98) referring to file permission
> problems that we are also experiencing, with the netatalk+asun code
> (2.1.1-4). Our target OS is FreeBSD 2.2.7.
>
> The two main points made below:
> 1) The setgid bit on directories is a problem:
> When the user is not a member of the group that owns a directory,
> then they cannot enable the setgid bit on the directory. This results
> in an error message to the Mac. This is especially a problem with the
> "nobody" user (guest file access).
> What does a "real" Macintosh do?
>
[...]

>
> A similar problem is specific to Unices like Linux that use the setgid
> bit on a directory to determine whether files created in that directory
> are assigned the group of the directory or the primary group of the
> user. When this is the case afpd should always turn on setgid for
> directories so that files have the group of the directory; however again
> it is hit-and-miss, it will sometimes create directories with setgid
> off. This is a problem if you use group privileges to share an afpd
> volume among multiple users; if any of the users are in a different
> primary group (meaning they are in the volume's group by secondary
> membership), missing setgid bits will cause files to be created with
> the wrong group which will make those files unreadable to some of the
> other users of the volume.

On FreeBSD-current you can use the SUID bit on directories (in -current)
to do a similar thing (if you have that option enebled in the kernel
and mount the file system with the right switch). It transfers OWNERSHIPS
of files to the owner of the folder. This is experimental
but has been proven to have some significant flaws and I may remove that
code again. The main reason is so that people can delete stuff intheir own
folder, but it fails in some funny cases and there are no easy fixes.

julian



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