From tuc@e-nfs-01.ame.admarketplace.net  Mon Mar 18 20:41:10 2013
Return-Path: <tuc@e-nfs-01.ame.admarketplace.net>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1])
	by hub.freebsd.org (Postfix) with ESMTP id 74637DCE
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 18 Mar 2013 20:41:10 +0000 (UTC)
	(envelope-from tuc@e-nfs-01.ame.admarketplace.net)
Received: from e-nfs-01.ame.admarketplace.net (e-nfs-01.ame.admarketplace.net [108.60.142.188])
	by mx1.freebsd.org (Postfix) with ESMTP id 386D6958
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 18 Mar 2013 20:41:10 +0000 (UTC)
Received: from e-nfs-01.ame.admarketplace.net (localhost [127.0.0.1])
	by e-nfs-01.ame.admarketplace.net (8.14.5/8.14.5) with ESMTP id r2J0eG7l001311
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 18 Mar 2013 20:40:16 -0400 (EDT)
	(envelope-from tuc@e-nfs-01.ame.admarketplace.net)
Received: (from tuc@localhost)
	by e-nfs-01.ame.admarketplace.net (8.14.5/8.14.5/Submit) id r2J0eGll001310;
	Mon, 18 Mar 2013 20:40:16 -0400 (EDT)
	(envelope-from tuc)
Message-Id: <201303190040.r2J0eGll001310@e-nfs-01.ame.admarketplace.net>
Date: Mon, 18 Mar 2013 20:40:16 -0400 (EDT)
From: Tuc <tuc@t-b-o-h.net>
Reply-To: Tuc <tuc@t-b-o-h.net>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: Wrong gid on file creations
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         177087
>Category:       kern
>Synopsis:       Wrong gid on file creations
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Mar 18 20:50:00 UTC 2013
>Closed-Date:    Thu Mar 21 21:59:26 UTC 2013
>Last-Modified:  Thu Mar 21 21:59:26 UTC 2013
>Originator:     Tuc
>Release:        FreeBSD 9.1-RELEASE amd64
>Organization:
TBOH
>Environment:
System: FreeBSD e-nfs-01.ame.admarketplace.net 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec 4 09:23:10 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64


>Description:
	Fresh install, create new user, touch /tmp/foo, see wrong gid
>How-To-Repeat:
$ cd /tmp
$ touch foo
$ ls -l foo
-rw-r--r--  1 tuc  wheel  0 Mar 18 20:36 foo
$ grep tuc /etc/passwd
tuc:*:1001:1001:Tuc:/home/tuc:/bin/sh
$ id
uid=1001(tuc) gid=1001(tuc) groups=1001(tuc),0(wheel)
$ cd /var/tmp
$ touch foo
$ ls -l foo
-rw-r--r--  1 tuc  wheel  0 Mar 18 20:37 foo

root@e-nfs-01:/root # mkdir /foo
root@e-nfs-01:/root # chmod 777 /foo
root@e-nfs-01:/root # exit
logout
$ cd /foo
$ touch foo
$ ls -l foo
-rw-r--r--  1 tuc  wheel  0 Mar 18 20:39 foo

>Fix:

>Release-Note:
>Audit-Trail:

From: Lowell Gilbert <freebsd-bugs-local@be-well.ilk.org>
To: Tuc <tuc@t-b-o-h.net>
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: kern/177087: Wrong gid on file creations
Date: Mon, 18 Mar 2013 17:24:14 -0400

 Tuc <tuc@t-b-o-h.net> writes:
 
 >>How-To-Repeat:
 > $ cd /tmp
 > $ touch foo
 > $ ls -l foo
 > -rw-r--r--  1 tuc  wheel  0 Mar 18 20:36 foo
 > $ grep tuc /etc/passwd
 > tuc:*:1001:1001:Tuc:/home/tuc:/bin/sh
 > $ id
 > uid=1001(tuc) gid=1001(tuc) groups=1001(tuc),0(wheel)
 > $ cd /var/tmp
 > $ touch foo
 > $ ls -l foo
 > -rw-r--r--  1 tuc  wheel  0 Mar 18 20:37 foo
 >
 > root@e-nfs-01:/root # mkdir /foo
 > root@e-nfs-01:/root # chmod 777 /foo
 > root@e-nfs-01:/root # exit
 > logout
 > $ cd /foo
 > $ touch foo
 > $ ls -l foo
 > -rw-r--r--  1 tuc  wheel  0 Mar 18 20:39 foo
 
 What group were you expecting?
 
 Those directories normally belong to the wheel group, so new
 subdirectories will be too.

From: Tuc <tuc@t-b-o-h.net>
To: Lowell Gilbert <freebsd-bugs-local@be-well.ilk.org>
Cc: <freebsd-gnats-submit@freebsd.org>
Subject: Re: kern/177087: Wrong gid on file creations
Date: Tue, 19 Mar 2013 16:18:51 -0400

 On 2013-03-18 17:24, Lowell Gilbert wrote:
 > Tuc <tuc@t-b-o-h.net> writes:
 >
 >>>How-To-Repeat:
 >> $ cd /tmp
 >> $ touch foo
 >> $ ls -l foo
 >> -rw-r--r--  1 tuc  wheel  0 Mar 18 20:36 foo
 >> $ grep tuc /etc/passwd
 >> tuc:*:1001:1001:Tuc:/home/tuc:/bin/sh
 >> $ id
 >> uid=1001(tuc) gid=1001(tuc) groups=1001(tuc),0(wheel)
 >> $ cd /var/tmp
 >> $ touch foo
 >> $ ls -l foo
 >> -rw-r--r--  1 tuc  wheel  0 Mar 18 20:37 foo
 >>
 >> root@e-nfs-01:/root # mkdir /foo
 >> root@e-nfs-01:/root # chmod 777 /foo
 >> root@e-nfs-01:/root # exit
 >> logout
 >> $ cd /foo
 >> $ touch foo
 >> $ ls -l foo
 >> -rw-r--r--  1 tuc  wheel  0 Mar 18 20:39 foo
 >
 > What group were you expecting?
 >
 > Those directories normally belong to the wheel group, so new
 > subdirectories will be too.
 Hi,
 
 Expecting the primary group listed on my id. I guess I never realized 
 that it used the parents group. I expected it to give the id/group that 
 I belong to.
 
 The basis of the reason for my interest is that I'm trying to use 
 NAS4Free, and when I create a volume and export it out NFS, every file 
 is getting the wheel group there too. I'm expecting it to pick up the 
 group of the user like our NetApp does. I tested on Linux, and when I do 
 the same things in /foo it creates it with my id/group, not the one 
 above. If I was to just use a normal FreeBSD NFS setup, how can I make 
 it pick up the user/group of the person creating the file (We are using 
 it exported to a farm of CentOS...We wanted FreeBSD due to ZFS).
 
 Thanks

From: Lowell Gilbert <freebsd-bugs-local@be-well.ilk.org>
To: Tuc <tuc@t-b-o-h.net>
Cc: <freebsd-gnats-submit@freebsd.org>
Subject: Re: kern/177087: Wrong gid on file creations
Date: Wed, 20 Mar 2013 11:34:45 -0400

 Tuc <tuc@t-b-o-h.net> writes:
 
 > On 2013-03-18 17:24, Lowell Gilbert wrote:
 >> Tuc <tuc@t-b-o-h.net> writes:
 >>
 >>>>How-To-Repeat:
 >>> $ cd /tmp
 >>> $ touch foo
 >>> $ ls -l foo
 >>> -rw-r--r--  1 tuc  wheel  0 Mar 18 20:36 foo
 >>> $ grep tuc /etc/passwd
 >>> tuc:*:1001:1001:Tuc:/home/tuc:/bin/sh
 >>> $ id
 >>> uid=1001(tuc) gid=1001(tuc) groups=1001(tuc),0(wheel)
 >>> $ cd /var/tmp
 >>> $ touch foo
 >>> $ ls -l foo
 >>> -rw-r--r--  1 tuc  wheel  0 Mar 18 20:37 foo
 >>>
 >>> root@e-nfs-01:/root # mkdir /foo
 >>> root@e-nfs-01:/root # chmod 777 /foo
 >>> root@e-nfs-01:/root # exit
 >>> logout
 >>> $ cd /foo
 >>> $ touch foo
 >>> $ ls -l foo
 >>> -rw-r--r--  1 tuc  wheel  0 Mar 18 20:39 foo
 >>
 >> What group were you expecting?
 >>
 >> Those directories normally belong to the wheel group, so new
 >> subdirectories will be too.
 
 >
 > Expecting the primary group listed on my id. I guess I never realized
 > that it used the parents group. I expected it to give the id/group
 > that I belong to.
 
 On some systems (SystemV-ish), the euid/egid are used by default, and I
 think the sgid bit can be set on the directory to change that to the BSD
 style. The BSD behaviour is the only one that POSIX requires.
 
 I believe that ACLs can be used to get the type of permissions you want,
 but I don't know the syntax offhand.
 
 > The basis of the reason for my interest is that I'm trying to use
 > NAS4Free, and when I create a volume and export it out NFS, every file
 > is getting the wheel group there too. I'm expecting it to pick up the
 > group of the user like our NetApp does. I tested on Linux, and when I
 > do the same things in /foo it creates it with my id/group, not the one
 > above. If I was to just use a normal FreeBSD NFS setup, how can I make
 > it pick up the user/group of the person creating the file (We are
 > using it exported to a farm of CentOS...We wanted FreeBSD due to ZFS).
 
 Normally, for directories where anyone can create their own files or
 directories, we use the sticky bit. /tmp is set up this way, for example.
 And normally every account has a home directory, owned by them and their
 personal group.

From: Tuc <tuc@t-b-o-h.net>
To: Lowell Gilbert <freebsd-bugs-local@be-well.ilk.org>
Cc: <freebsd-gnats-submit@freebsd.org>
Subject: Re: kern/177087: Wrong gid on file creations
Date: Thu, 21 Mar 2013 13:21:30 -0400

 On 2013-03-20 11:34, Lowell Gilbert wrote:
 > Tuc <tuc@t-b-o-h.net> writes:
 >
 >> On 2013-03-18 17:24, Lowell Gilbert wrote:
 >>> Tuc <tuc@t-b-o-h.net> writes:
 >>>
 >>>>>How-To-Repeat:
 >>>> $ cd /tmp
 >>>> $ touch foo
 >>>> $ ls -l foo
 >>>> -rw-r--r--  1 tuc  wheel  0 Mar 18 20:36 foo
 >>>> $ grep tuc /etc/passwd
 >>>> tuc:*:1001:1001:Tuc:/home/tuc:/bin/sh
 >>>> $ id
 >>>> uid=1001(tuc) gid=1001(tuc) groups=1001(tuc),0(wheel)
 >>>> $ cd /var/tmp
 >>>> $ touch foo
 >>>> $ ls -l foo
 >>>> -rw-r--r--  1 tuc  wheel  0 Mar 18 20:37 foo
 >>>>
 >>>> root@e-nfs-01:/root # mkdir /foo
 >>>> root@e-nfs-01:/root # chmod 777 /foo
 >>>> root@e-nfs-01:/root # exit
 >>>> logout
 >>>> $ cd /foo
 >>>> $ touch foo
 >>>> $ ls -l foo
 >>>> -rw-r--r--  1 tuc  wheel  0 Mar 18 20:39 foo
 >>>
 >>> What group were you expecting?
 >>>
 >>> Those directories normally belong to the wheel group, so new
 >>> subdirectories will be too.
 >
 >>
 >> Expecting the primary group listed on my id. I guess I never 
 >> realized
 >> that it used the parents group. I expected it to give the id/group
 >> that I belong to.
 >
 > On some systems (SystemV-ish), the euid/egid are used by default, and 
 > I
 > think the sgid bit can be set on the directory to change that to the 
 > BSD
 > style. The BSD behaviour is the only one that POSIX requires.
 >
 > I believe that ACLs can be used to get the type of permissions you 
 > want,
 > but I don't know the syntax offhand.
 >
 >> The basis of the reason for my interest is that I'm trying to use
 >> NAS4Free, and when I create a volume and export it out NFS, every 
 >> file
 >> is getting the wheel group there too. I'm expecting it to pick up 
 >> the
 >> group of the user like our NetApp does. I tested on Linux, and when 
 >> I
 >> do the same things in /foo it creates it with my id/group, not the 
 >> one
 >> above. If I was to just use a normal FreeBSD NFS setup, how can I 
 >> make
 >> it pick up the user/group of the person creating the file (We are
 >> using it exported to a farm of CentOS...We wanted FreeBSD due to 
 >> ZFS).
 >
 > Normally, for directories where anyone can create their own files or
 > directories, we use the sticky bit. /tmp is set up this way, for 
 > example.
 > And normally every account has a home directory, owned by them and 
 > their
 > personal group.
 
 Alright. I appreciate your help and explanation . I guess we can close 
 this with "end user ignorant" as the resolution. :)
 
 Thanks, Tuc
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Thu Mar 21 21:59:08 UTC 2013 
State-Changed-Why:  
Apparently working as designed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=177087 
>Unformatted:
