Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Sep 2009 12:36:57 +0200
From:      Adrian Penisoara <ady@freebsd.ady.ro>
To:        Nate Eldredge <nate@thatsmathematics.com>
Cc:        freebsd-hackers@freebsd.org, Giulio Ferro <auryn@zirakzigil.org>
Subject:   Re: ZFS group ownership
Message-ID:  <78cb3d3f0909160336m2d1f93dsad4aafb692395a80@mail.gmail.com>
In-Reply-To: <Pine.GSO.4.64.0909151507080.8152@zeno.ucsd.edu>
References:  <4AAB8AD0.5010302@zirakzigil.org> <Pine.GSO.4.64.0909151507080.8152@zeno.ucsd.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

On Wed, Sep 16, 2009 at 12:18 AM, Nate Eldredge
<nate@thatsmathematics.com> wrote:
[...]
> [On UFS, files are created with the same group as the directory that
> contains them. =A0On ZFS, they are created with the primary group of the =
user
> who creates them.]
>
>> What I ask now is: is this a bug or a feature?
>
> Both, I think :)
>
> The behavior you describe on UFS (group comes from the directory) is
> standard for BSD-based systems like FreeBSD. =A0On SysV-based systems,
> however, the default is that the group comes from the user, as you descri=
be
> on ZFS. =A0ZFS was originally developed for Solaris, a descendent of SysV=
, so
> it's not surprising that it also has this behavior. =A0However, this is a=
t
> least a documentation bug, since the open(2) man page describes the BSD
> behavior without mentioning exceptions.

Is the ownership of the new file decided by the open() syscall or by
the filesystem layer ?
On a superficial lookup through the sources it appears a filesystem
layer choice...

Which of the following would then be the best option (also taking POLA
into account):
 * leave things are they are
 * make ZFS under FreeBSD behave the way open(2) describes
 * have a new ZFS property govern the behavior and default to one of the ab=
ove

Thanks,
Adrian Penisoara
EnterpriseBSD



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?78cb3d3f0909160336m2d1f93dsad4aafb692395a80>