ZFS group ownership

Romain Tartière romain at blogreen.org
Wed Sep 16 11:12:38 UTC 2009


On Tue, Sep 15, 2009 at 03:18:41PM -0700, Nate Eldredge wrote:
> >What I ask now is: is this a bug or a feature?
> 
> Both, I think :)

Or none, just different implementation of the same open() function
complying with the Open Group Base Specifications ;-)

Quotting
http://www.opengroup.org/onlinepubs/009695399/functions/open.html

----------------8<------------------------------------------------------
O_CREAT
  [...] the file shall be created; the user ID of the file shall be set
  to the effective user ID of the process; the group ID of the file
  shall be set to the group ID of the file's parent directory or to the
  effective group ID of the process [...] Implementations shall provide
  a way to initialize the file's group ID to the group ID of the parent
  directory. Implementations may, but need not, provide an
  implementation-defined way to initialize the file's group ID to the
  effective group ID of the calling process.

[...]

The POSIX.1-1990 standard required that the group ID of a newly created
file be set to the group ID of its parent directory or to the effective
group ID of the creating process. FIPS 151-2 required that
implementations provide a way to have the group ID be set to the group
ID of the containing directory, but did not prohibit implementations
also supporting a way to set the group ID to the effective group ID of
the creating process. Conforming applications should not assume which
group ID will be used. If it matters, an application can use chown() to
set the group ID after the file is created, or determine under what
conditions the implementation will set the desired group ID.
----------------8<------------------------------------------------------


This being said, two different behaviour on the same system, even if you
« should not assume which group ID will be used », is kind of weird.

-- 
Romain Tartière <romain at blogreen.org>        http://romain.blogreen.org/
pgp: 8DAB A124 0DA4 7024 F82A  E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20090916/304b3ec0/attachment.pgp


More information about the freebsd-hackers mailing list