From owner-freebsd-fs@FreeBSD.ORG Mon Oct 17 07:25:46 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6795616A41F; Mon, 17 Oct 2005 07:25:46 +0000 (GMT) (envelope-from rebehn@ant.uni-bremen.de) Received: from antsrv1.ant.uni-bremen.de (antsrv1.ant.uni-bremen.de [134.102.176.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC24943D48; Mon, 17 Oct 2005 07:25:45 +0000 (GMT) (envelope-from rebehn@ant.uni-bremen.de) Received: from bremerhaven.ant.uni-bremen.de ([134.102.176.10]) by antsrv1.ant.uni-bremen.de with esmtp (Exim 4.54 (FreeBSD)) id 1ERPNP-000EKL-Jv; Mon, 17 Oct 2005 09:25:43 +0200 Message-ID: <435351F7.10101@ant.uni-bremen.de> Date: Mon, 17 Oct 2005 09:25:43 +0200 From: Heinrich Rebehn User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050831 Debian/1.7.8-1sarge2 X-Accept-Language: en MIME-Version: 1.0 To: Robert Watson References: <434F4FF8.9050903@ant.uni-bremen.de> <20051014064145.GA40856@admin.sibptus.tomsk.ru> <434F9DAE.6070607@ant.uni-bremen.de> <20051014134820.GA43849@admin.sibptus.tomsk.ru> <20051014203021.L66014@fledge.watson.org> In-Reply-To: <20051014203021.L66014@fledge.watson.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: Problem with default ACLs and mask X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 07:25:46 -0000 Robert Watson wrote: > > On Fri, 14 Oct 2005, Victor Sudakov wrote: > >> Heinrich Rebehn wrote: >> >>> >>> As you can see, it works for the dirs created by hand, but not for >>> the dir created by tar. >> >> >> I think tar does a chmod on extracted files because it stores and >> extracts permission information. I really see no way of working around >> this. >> >> However, I think those people who designed POSIX ACLs might have had a >> solution for this problem, it is too common. > > > Our tar speaks ACLs, but I'm not sure what model it uses to decide what > to do with the default ACL of the directory where the tar is extracted. > It could well be that tar specifically restores ACLs, overriding the > default ACL where the files are untar'd. > > Robert N M Watson It happens even when the tar is extracted on a Linux system via NFS, so i do not think that tar restores ACL's here. However it does restore file permissions looking into the archive shows: -bash-2.05b$ tar tzvf \ /export/linux/root/debian/usr/local/src/TARS/STonX-0.6.5.tar.gz |more drwx--x--x 0 root root 0 Feb 9 1996 STonX-0.6.5/ ... So there is in fact no write permission for group. Doing this by hand: -bash-2.05b$ umask 0 -bash-2.05b$ mkdir D3 -bash-2.05b$ ls -lod D3 drwxrwx---+ 2 a1 ntlab - 512 Oct 17 09:22 D3 -bash-2.05b$ getfacl D3 #file:D3 #owner:624 #group:1022 user::rwx group::--- group:wiss:rwx mask::rwx other::--- -bash-2.05b$ chmod g-w D3 -bash-2.05b$ ls -lod D3 drwxr-x---+ 2 a1 ntlab - 512 Oct 17 09:22 D3 -bash-2.05b$ getfacl D3 #file:D3 #owner:624 #group:1022 user::rwx group::--- group:wiss:rwx # effective: r-x mask::r-x other::--- Why is the write bit of the mask reset when removing write perms for group? Is this really intended? This does not make sense to me, because both permissions pertain to different groups. --Heinrich From owner-freebsd-fs@FreeBSD.ORG Mon Oct 17 09:10:26 2005 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA7C216A41F for ; Mon, 17 Oct 2005 09:10:26 +0000 (GMT) (envelope-from rebehn@ant.uni-bremen.de) Received: from antsrv1.ant.uni-bremen.de (antsrv1.ant.uni-bremen.de [134.102.176.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6176043D46 for ; Mon, 17 Oct 2005 09:10:25 +0000 (GMT) (envelope-from rebehn@ant.uni-bremen.de) Received: from bremerhaven.ant.uni-bremen.de ([134.102.176.10]) by antsrv1.ant.uni-bremen.de with esmtp (Exim 4.54 (FreeBSD)) id 1ERR0i-000F3G-T3; Mon, 17 Oct 2005 11:10:25 +0200 Message-ID: <43536A80.2040502@ant.uni-bremen.de> Date: Mon, 17 Oct 2005 11:10:24 +0200 From: Heinrich Rebehn User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050831 Debian/1.7.8-1sarge2 X-Accept-Language: en MIME-Version: 1.0 To: Nicolas KOWALSKI References: <20051014160128.hev160v52ossokg0@wwws.cs.ait.ac.th> <20051014045824.V5343@odysseus.silby.com> <434FD761.3050506@centtech.com> <434FEDC6.4040405@centtech.com> <434FFAD6.6000002@ant.uni-bremen.de> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@FreeBSD.org Subject: Re: FreeBSD NFS server not responding to TCP SYN packets from Linux/SunOS clients X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 09:10:27 -0000 Nicolas KOWALSKI wrote: > Heinrich Rebehn writes: > > >>Nicolas KOWALSKI wrote: >> >>>Eric Anderson writes: >>> >>> >>>>Nicolas KOWALSKI wrote: >>>> >>>> >>>>>Eric Anderson writes: >>>>> >>>>> >>>>>>Nicolas KOWALSKI wrote: >>>>>> >>>>>> >>>>>>>Mike Silbersack writes: >>>>>>> >>>>>>> >>>>>>>>Actually, there may be a quick fix for this specific machine. >>>>>>>>If you set net.inet.tcp.keepidle to 1 minute (60*whatever >>>>>>>>kern.hz is), that'll cause keepalive packets to be sent every >>>>>>>>minute to an idle connection, rather than every 2 hours. That >>>>>>>>would kill the stuck connections much quicker. >>>>> >>>>>>>Unfortunately, this does not work as expected. I just tested >>>>>>>with my workstation (Linux 2.6), with NFS filesystems mounted >>>>>>>with TCP; when the station rebooted abruptely, mounting the same >>>>>>>NFS filesystems hung more than 1 minute (15 minutes just >>>>>>>now). During this hang, I saw on the server, using netstat, the >>>>>>>nfsd process related to my workstation in ESTABLISHED state. >>>>>> >>>>>>Man fixmount? >>>>> >>>>>This is a FreeBSD-only command apparently. I did not find it on >>>>>Linux or Solaris. It could have been useful, by calling it before >>>>>NFS filesystems are mounted on clients, yes. >>>> >>>>It's available on Fedora Core 2 and 3 at least. > > >>>So, its a non-option, because we are only using Debian Sarge and >>>Solaris 9 UNIX workstations. :-( >> >>For Debian Sarge, it is in am-utils (amd automounter). > > > Oh, thanks for the information... > > >>Since we are bit by the same problem - we have diskless Linux >>clients that mount their root fs from a FreeBSD server, which >>sometimes takes some 15 minutes - i will try fixmount next week. > > > I just tried it without success. I call it just before > /etc/rcS.d/S45mountnfs, and it does not help. > > It looks "normal" for me, because the hang (visible on the etherreal > trace) does not happen at mount call, but when requesting the SYN to > the nfsd port on the server. > Oh, that is bad news. But might it be possible to write a small program on the client side that would tell the server to close the connection? Unfortunately my network programming knowledge is very limitied, but if someone could give me an idea, i would be willing to experiment. After all, this is a very annoying problem :-( --Heinrich From owner-freebsd-fs@FreeBSD.ORG Mon Oct 17 12:24:41 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A23A016A41F for ; Mon, 17 Oct 2005 12:24:41 +0000 (GMT) (envelope-from Nicolas.Kowalski@imag.fr) Received: from imag.imag.fr (imag.imag.fr [129.88.30.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D151943D46 for ; Mon, 17 Oct 2005 12:24:40 +0000 (GMT) (envelope-from Nicolas.Kowalski@imag.fr) Received: from mail-veri.imag.fr (mail-veri.imag.fr [129.88.43.52]) by imag.imag.fr (8.13.0/8.13.0) with ESMTP id j9HCOZpS008825 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 17 Oct 2005 14:24:36 +0200 (CEST) Received: from corbeau.imag.fr ([129.88.43.162]) by mail-veri.imag.fr with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1ERU2d-0007ie-QB for freebsd-fs@freebsd.org; Mon, 17 Oct 2005 14:24:35 +0200 Date: Mon, 17 Oct 2005 14:24:35 +0200 From: Nicolas KOWALSKI To: freebsd-fs@freebsd.org In-Reply-To: Message-ID: References: <20051014160128.hev160v52ossokg0@wwws.cs.ait.ac.th> <20051014045824.V5343@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (imag.imag.fr [129.88.30.1]); Mon, 17 Oct 2005 14:24:36 +0200 (CEST) X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-Information: Please contact the ISP for more information Subject: [UPDATE] Re: FreeBSD NFS server not responding to TCP SYN packets from Linux/SunOS clients X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 12:24:41 -0000 On Fri, 14 Oct 2005, Nicolas KOWALSKI wrote: > Mike Silbersack writes: > > Actually, there may be a quick fix for this specific machine. If > > you set net.inet.tcp.keepidle to 1 minute (60*whatever kern.hz is), > > that'll cause keepalive packets to be sent every minute to an idle > > connection, rather than every 2 hours. That would kill the stuck > > connections much quicker. > > Unfortunately, this does not work as expected. I just tested with my > workstation (Linux 2.6), with NFS filesystems mounted with TCP; when > the station rebooted abruptely, mounting the same NFS filesystems hung > more than 1 minute (15 minutes just now). During this hang, I saw on > the server, using netstat, the nfsd process related to my workstation > in ESTABLISHED state. Thanks to Olivier, his suggestion to restart the nfsd processes after setting net.inet.tcp.keepidle makes the situation much better ! Now, this work as expected ; Linux and SunOS workstations do not hang more than a few seconds when mounting shares from the FreeBSD server after an unclean shutdown. I am still waiting for other problems to come up with this configuration, but after a few hours, it just looks really good. :-) Many thanks to all ! Best regards, -- Nicolas From owner-freebsd-fs@FreeBSD.ORG Mon Oct 17 13:46:21 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6454316A41F for ; Mon, 17 Oct 2005 13:46:21 +0000 (GMT) (envelope-from rebehn@ant.uni-bremen.de) Received: from antsrv1.ant.uni-bremen.de (antsrv1.ant.uni-bremen.de [134.102.176.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id C649143D49 for ; Mon, 17 Oct 2005 13:46:20 +0000 (GMT) (envelope-from rebehn@ant.uni-bremen.de) Received: from bremerhaven.ant.uni-bremen.de ([134.102.176.10]) by antsrv1.ant.uni-bremen.de with esmtp (Exim 4.54 (FreeBSD)) id 1ERVJf-000GTO-PG; Mon, 17 Oct 2005 15:46:15 +0200 Message-ID: <4353AB27.6070409@ant.uni-bremen.de> Date: Mon, 17 Oct 2005 15:46:15 +0200 From: Heinrich Rebehn User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050831 Debian/1.7.8-1sarge2 X-Accept-Language: en MIME-Version: 1.0 To: Nicolas KOWALSKI References: <20051014160128.hev160v52ossokg0@wwws.cs.ait.ac.th> <20051014045824.V5343@odysseus.silby.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org Subject: Re: [UPDATE] Re: FreeBSD NFS server not responding to TCP SYN packets from Linux/SunOS clients X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 13:46:21 -0000 Nicolas KOWALSKI wrote: > On Fri, 14 Oct 2005, Nicolas KOWALSKI wrote: > > >>Mike Silbersack writes: > > >>>Actually, there may be a quick fix for this specific machine. If >>>you set net.inet.tcp.keepidle to 1 minute (60*whatever kern.hz is), >>>that'll cause keepalive packets to be sent every minute to an idle >>>connection, rather than every 2 hours. That would kill the stuck >>>connections much quicker. >> >>Unfortunately, this does not work as expected. I just tested with my >>workstation (Linux 2.6), with NFS filesystems mounted with TCP; when >>the station rebooted abruptely, mounting the same NFS filesystems hung >>more than 1 minute (15 minutes just now). During this hang, I saw on >>the server, using netstat, the nfsd process related to my workstation >>in ESTABLISHED state. > > > Thanks to Olivier, his suggestion to restart the nfsd processes after > setting net.inet.tcp.keepidle makes the situation much better ! > > Now, this work as expected ; Linux and SunOS workstations do not hang > more than a few seconds when mounting shares from the FreeBSD server > after an unclean shutdown. I am still waiting for other problems to come > up with this configuration, but after a few hours, it just looks really > good. :-) > > Many thanks to all ! > > Best regards, Great news. I will give that a try. Still, i wonder if it is possible to have the server close the open connections with a small program that one could call before the first mount. Can someone give me a hint? --Heinrich -- Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-4664 Fax : -3341 From owner-freebsd-fs@FreeBSD.ORG Mon Oct 17 14:16:16 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A3A316A41F; Mon, 17 Oct 2005 14:16:16 +0000 (GMT) (envelope-from sudakov@sibptus.tomsk.ru) Received: from relay2.tomsk.ru (relay2.tomsk.ru [212.73.124.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 151C243D5F; Mon, 17 Oct 2005 14:16:10 +0000 (GMT) (envelope-from sudakov@sibptus.tomsk.ru) X-Virus-Scanned: by Dr.Web (R) daemon for FreeBSD, version 4.32.1 (2004-08-30) at relay2.tomsk.ru Received: from [172.16.138.125] (account sudakovva@sibptus.tomsk.ru HELO admin.sibptus.tomsk.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 4.3.2) with ESMTPSA id 1388581; Mon, 17 Oct 2005 21:16:09 +0700 Received: (from sudakov@localhost) by admin.sibptus.tomsk.ru (8.12.9p2/8.12.9/Submit) id j9HEG9Fs083747; Mon, 17 Oct 2005 21:16:09 +0700 (OMSST) (envelope-from sudakov@sibptus.tomsk.ru) X-Authentication-Warning: admin.sibptus.tomsk.ru: sudakov set sender to sudakov@sibptus.tomsk.ru using -f Date: Mon, 17 Oct 2005 21:16:09 +0700 From: Victor Sudakov To: Heinrich Rebehn Message-ID: <20051017141609.GA83692@admin.sibptus.tomsk.ru> References: <434F4FF8.9050903@ant.uni-bremen.de> <20051014064145.GA40856@admin.sibptus.tomsk.ru> <434F9DAE.6070607@ant.uni-bremen.de> <20051014134820.GA43849@admin.sibptus.tomsk.ru> <20051014203021.L66014@fledge.watson.org> <435351F7.10101@ant.uni-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <435351F7.10101@ant.uni-bremen.de> User-Agent: Mutt/1.4.2.1i Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://vas.tomsk.ru/vas.asc Cc: freebsd-fs@freebsd.org, Robert Watson Subject: Re: Problem with default ACLs and mask X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 14:16:16 -0000 Heinrich Rebehn wrote: > > Why is the write bit of the mask reset when removing write perms for > group? Is this really intended? Yes, it is intended, whether it was a good idea or not. Quoting from setfacl(1) Traditional POSIX interfaces acting on file system object modes have mod- ified semantics in the presence of POSIX.1e extended ACLs. When a mask entry is present on the access ACL of an object, the mask entry is sub- stituted for the group bits; this occurs in programs such as stat(1) or > ls(1). When the mode is modified on an object that has a mask entry, the > changes applied to the group bits will actually be applied to the mask > entry. These semantics provide for greater application compatibility: applications modifying the mode instead of the ACL will see conservative behavior, limiting the effective rights granted by all of the additional user and group entries; this occurs in programs such as chmod(1). -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From owner-freebsd-fs@FreeBSD.ORG Mon Oct 17 19:30:01 2005 Return-Path: X-Original-To: fs@freebsd.org Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04EAB16A422 for ; Mon, 17 Oct 2005 19:30:00 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9692B43D49 for ; Mon, 17 Oct 2005 19:30:00 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9HJU0tJ007910; Mon, 17 Oct 2005 12:30:00 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9HJTxSY007909; Mon, 17 Oct 2005 12:29:59 -0700 Date: Mon, 17 Oct 2005 12:29:59 -0700 From: Brooks Davis To: Jim Rees Message-ID: <20051017192959.GB15097@odin.ac.hmc.edu> References: <20051014162122.8D1571BBDE@citi.umich.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i9LlY+UWpKt15+FH" Content-Disposition: inline In-Reply-To: <20051014162122.8D1571BBDE@citi.umich.edu> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: fs@freebsd.org, rick@snowhite.cis.uoguelph.ca Subject: Re: FreeBSD NFS server not responding to TCP SYN packets from Linux/SunOS clients X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2005 19:30:01 -0000 --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 14, 2005 at 12:21:22PM -0400, Jim Rees wrote: > ps: It would be nice if someone with the right expertise could explore > other things in TCP specifically for NFS. For example, I don't see > why a retransmit timeout should go above about 100msec >=20 > nfs/rpc shouldn't retransmit at all over tcp except when there has been a > reconnect. Tcp might retransmit, but modern implementations will always > choose the right timeout dynamically, unless packet loss is excessive. That's not entierly true. I was talking to someone from Panasas last fall who was lamenting the lack of sub millisecond timeout support in the kernel because on a Gigabit Ethernet LAN, you can expect a response in less than 1ms and essentily all failures to respond in that time are caused by packet corruption or overflowing switch buffers. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --i9LlY+UWpKt15+FH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDU/u0XY6L6fI4GtQRAgxgAJ9gNr7vrvuAz7xTWgORz2BvxQCC3gCfX5fy 6J4tiVp3Oaqsib1+bDXGtD0= =sHox -----END PGP SIGNATURE----- --i9LlY+UWpKt15+FH-- From owner-freebsd-fs@FreeBSD.ORG Tue Oct 18 11:11:16 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BED116A41F; Tue, 18 Oct 2005 11:11:16 +0000 (GMT) (envelope-from rebehn@ant.uni-bremen.de) Received: from antsrv1.ant.uni-bremen.de (antsrv1.ant.uni-bremen.de [134.102.176.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0346A43D48; Tue, 18 Oct 2005 11:11:15 +0000 (GMT) (envelope-from rebehn@ant.uni-bremen.de) Received: from bremerhaven.ant.uni-bremen.de ([134.102.176.10]) by antsrv1.ant.uni-bremen.de with esmtp (Exim 4.54 (FreeBSD)) id 1ERpNB-000FT9-Di; Tue, 18 Oct 2005 13:11:13 +0200 Message-ID: <4354D850.8060908@ant.uni-bremen.de> Date: Tue, 18 Oct 2005 13:11:12 +0200 From: Heinrich Rebehn User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050831 Debian/1.7.8-1sarge2 X-Accept-Language: en MIME-Version: 1.0 To: Victor Sudakov References: <434F4FF8.9050903@ant.uni-bremen.de> <20051014064145.GA40856@admin.sibptus.tomsk.ru> <434F9DAE.6070607@ant.uni-bremen.de> <20051014134820.GA43849@admin.sibptus.tomsk.ru> <20051014203021.L66014@fledge.watson.org> <435351F7.10101@ant.uni-bremen.de> <20051017141609.GA83692@admin.sibptus.tomsk.ru> In-Reply-To: <20051017141609.GA83692@admin.sibptus.tomsk.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Robert Watson Subject: Re: Problem with default ACLs and mask X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2005 11:11:16 -0000 Victor Sudakov wrote: > Heinrich Rebehn wrote: > >>Why is the write bit of the mask reset when removing write perms for >>group? Is this really intended? > > > Yes, it is intended, whether it was a good idea or not. > > Quoting from setfacl(1) > > Traditional POSIX interfaces acting on file system object modes have mod- > ified semantics in the presence of POSIX.1e extended ACLs. When a mask > entry is present on the access ACL of an object, the mask entry is sub- > stituted for the group bits; this occurs in programs such as stat(1) or > >> ls(1). When the mode is modified on an object that has a mask entry, the >> changes applied to the group bits will actually be applied to the mask >> entry. These semantics provide for greater application compatibility: > > applications modifying the mode instead of the ACL will see conservative > behavior, limiting the effective rights granted by all of the additional > user and group entries; this occurs in programs such as chmod(1). > > Very sad :-( It really seems to be impossible to implment something like a "Group Manager" enabling me to delegate priviliges for a group of users to some non-root person. Where is that code located so i could patch it myself? --Heinrich From owner-freebsd-fs@FreeBSD.ORG Tue Oct 18 11:21:40 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDE5916A420; Tue, 18 Oct 2005 11:21:40 +0000 (GMT) (envelope-from sudakov@sibptus.tomsk.ru) Received: from relay2.tomsk.ru (relay2.tomsk.ru [212.73.124.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E64C943D4C; Tue, 18 Oct 2005 11:21:38 +0000 (GMT) (envelope-from sudakov@sibptus.tomsk.ru) X-Virus-Scanned: by Dr.Web (R) daemon for FreeBSD, version 4.32.1 (2004-08-30) at relay2.tomsk.ru Received: from [172.16.138.125] (account sudakovva@sibptus.tomsk.ru HELO admin.sibptus.tomsk.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 4.3.2) with ESMTPSA id 1395653; Tue, 18 Oct 2005 18:21:35 +0700 Received: (from sudakov@localhost) by admin.sibptus.tomsk.ru (8.12.9p2/8.12.9/Submit) id j9IBLZQC094715; Tue, 18 Oct 2005 18:21:35 +0700 (OMSST) (envelope-from sudakov@sibptus.tomsk.ru) X-Authentication-Warning: admin.sibptus.tomsk.ru: sudakov set sender to sudakov@sibptus.tomsk.ru using -f Date: Tue, 18 Oct 2005 18:21:35 +0700 From: Victor Sudakov To: Heinrich Rebehn Message-ID: <20051018112135.GA94670@admin.sibptus.tomsk.ru> References: <434F4FF8.9050903@ant.uni-bremen.de> <20051014064145.GA40856@admin.sibptus.tomsk.ru> <434F9DAE.6070607@ant.uni-bremen.de> <20051014134820.GA43849@admin.sibptus.tomsk.ru> <20051014203021.L66014@fledge.watson.org> <435351F7.10101@ant.uni-bremen.de> <20051017141609.GA83692@admin.sibptus.tomsk.ru> <4354D850.8060908@ant.uni-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4354D850.8060908@ant.uni-bremen.de> User-Agent: Mutt/1.4.2.1i Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://vas.tomsk.ru/vas.asc Cc: freebsd-fs@freebsd.org, Robert Watson Subject: Re: Problem with default ACLs and mask X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2005 11:21:41 -0000 Heinrich Rebehn wrote: > >>Why is the write bit of the mask reset when removing write perms for > >>group? Is this really intended? > > > > > > Yes, it is intended, whether it was a good idea or not. [dd] > > > Very sad :-( It really seems to be impossible to implment something like > a "Group Manager" enabling me to delegate priviliges for a group of > users to some non-root person. What OS allows you to do it? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From owner-freebsd-fs@FreeBSD.ORG Tue Oct 18 12:10:50 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3545F16A420; Tue, 18 Oct 2005 12:10:50 +0000 (GMT) (envelope-from rebehn@ant.uni-bremen.de) Received: from antsrv1.ant.uni-bremen.de (antsrv1.ant.uni-bremen.de [134.102.176.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E6AD43D72; Tue, 18 Oct 2005 12:10:46 +0000 (GMT) (envelope-from rebehn@ant.uni-bremen.de) Received: from bremerhaven.ant.uni-bremen.de ([134.102.176.10]) by antsrv1.ant.uni-bremen.de with esmtp (Exim 4.54 (FreeBSD)) id 1ERqIm-000FvE-7r; Tue, 18 Oct 2005 14:10:44 +0200 Message-ID: <4354E644.7090608@ant.uni-bremen.de> Date: Tue, 18 Oct 2005 14:10:44 +0200 From: Heinrich Rebehn User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050831 Debian/1.7.8-1sarge2 X-Accept-Language: en MIME-Version: 1.0 To: Victor Sudakov References: <434F4FF8.9050903@ant.uni-bremen.de> <20051014064145.GA40856@admin.sibptus.tomsk.ru> <434F9DAE.6070607@ant.uni-bremen.de> <20051014134820.GA43849@admin.sibptus.tomsk.ru> <20051014203021.L66014@fledge.watson.org> <435351F7.10101@ant.uni-bremen.de> <20051017141609.GA83692@admin.sibptus.tomsk.ru> <4354D850.8060908@ant.uni-bremen.de> <20051018112135.GA94670@admin.sibptus.tomsk.ru> In-Reply-To: <20051018112135.GA94670@admin.sibptus.tomsk.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Robert Watson Subject: Re: Problem with default ACLs and mask X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2005 12:10:50 -0000 Victor Sudakov wrote: > Heinrich Rebehn wrote: > >>>>Why is the write bit of the mask reset when removing write perms for >>>>group? Is this really intended? >>> >>> >>>Yes, it is intended, whether it was a good idea or not. > > > [dd] > > >>Very sad :-( It really seems to be impossible to implment something like >>a "Group Manager" enabling me to delegate priviliges for a group of >>users to some non-root person. > > > What OS allows you to do it? > I have done such things with OpenVMS. Dunno how much control Windows/NTFS allows. --Heinrich From owner-freebsd-fs@FreeBSD.ORG Tue Oct 18 12:20:58 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F1DC16A41F for ; Tue, 18 Oct 2005 12:20:58 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9ED343D48 for ; Tue, 18 Oct 2005 12:20:57 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 2C22246B8C; Tue, 18 Oct 2005 08:20:56 -0400 (EDT) Date: Tue, 18 Oct 2005 13:20:56 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Heinrich Rebehn In-Reply-To: <4354E644.7090608@ant.uni-bremen.de> Message-ID: <20051018131405.M56080@fledge.watson.org> References: <434F4FF8.9050903@ant.uni-bremen.de> <20051014064145.GA40856@admin.sibptus.tomsk.ru> <434F9DAE.6070607@ant.uni-bremen.de> <20051014134820.GA43849@admin.sibptus.tomsk.ru> <20051014203021.L66014@fledge.watson.org> <435351F7.10101@ant.uni-bremen.de> <20051017141609.GA83692@admin.sibptus.tomsk.ru> <4354D850.8060908@ant.uni-bremen.de> <20051018112135.GA94670@admin.sibptus.tomsk.ru> <4354E644.7090608@ant.uni-bremen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: Problem with default ACLs and mask X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2005 12:20:58 -0000 On Tue, 18 Oct 2005, Heinrich Rebehn wrote: >> What OS allows you to do it? >> > I have done such things with OpenVMS. Dunno how much control > Windows/NTFS allows. NFSv4 ACLs have a facility along these lines, which is one of the reasons I've been investigating it. There are potential interactions with notions of setuid/setgid that need to be considered carefully, however. Supposedly Sun released a new IETF draft yesterday that will continue the dialog on how to combine UNIX semantics and NFSv4 semantics, but I haven't had a chance to pull it down yet. AFS had an alternative notion that I found quite useful -- they believe that objects don't have owners, only ACLs that give the rights associated with ownership to whomever is appropriate. They also dramatically simplified matters by putting ACLs only on directories, since their focus was user data, and saving the trouble of trying to manage ACLs on untold numbers of objects. However, this requires a clear notion of what directory a file is in, which isn't very compatible with the notion of hard links -- so AFS allows hard linking only within the same directory. Robert N M Watson From owner-freebsd-fs@FreeBSD.ORG Tue Oct 18 15:46:31 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A68C16A41F; Tue, 18 Oct 2005 15:46:31 +0000 (GMT) (envelope-from sudakov@sibptus.tomsk.ru) Received: from relay2.tomsk.ru (relay2.tomsk.ru [212.73.124.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD5C943D48; Tue, 18 Oct 2005 15:46:29 +0000 (GMT) (envelope-from sudakov@sibptus.tomsk.ru) X-Virus-Scanned: by Dr.Web (R) daemon for FreeBSD, version 4.32.1 (2004-08-30) at relay2.tomsk.ru Received: from [172.16.138.125] (account sudakovva@sibptus.tomsk.ru HELO admin.sibptus.tomsk.ru) by relay2.tomsk.ru (CommuniGate Pro SMTP 4.3.2) with ESMTPSA id 1397216; Tue, 18 Oct 2005 22:46:28 +0700 Received: (from sudakov@localhost) by admin.sibptus.tomsk.ru (8.12.9p2/8.12.9/Submit) id j9IFkRlL096057; Tue, 18 Oct 2005 22:46:27 +0700 (OMSST) (envelope-from sudakov@sibptus.tomsk.ru) X-Authentication-Warning: admin.sibptus.tomsk.ru: sudakov set sender to sudakov@sibptus.tomsk.ru using -f Date: Tue, 18 Oct 2005 22:46:27 +0700 From: Victor Sudakov To: Heinrich Rebehn Message-ID: <20051018154627.GB95892@admin.sibptus.tomsk.ru> References: <434F4FF8.9050903@ant.uni-bremen.de> <20051014064145.GA40856@admin.sibptus.tomsk.ru> <434F9DAE.6070607@ant.uni-bremen.de> <20051014134820.GA43849@admin.sibptus.tomsk.ru> <20051014203021.L66014@fledge.watson.org> <435351F7.10101@ant.uni-bremen.de> <20051017141609.GA83692@admin.sibptus.tomsk.ru> <4354D850.8060908@ant.uni-bremen.de> <20051018112135.GA94670@admin.sibptus.tomsk.ru> <4354E644.7090608@ant.uni-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4354E644.7090608@ant.uni-bremen.de> User-Agent: Mutt/1.4.2.1i Organization: AO "Svyaztransneft", SibPTUS X-PGP-Key: http://vas.tomsk.ru/vas.asc Cc: freebsd-fs@freebsd.org, Robert Watson Subject: Re: Problem with default ACLs and mask X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2005 15:46:31 -0000 Heinrich Rebehn wrote: > >>>>Why is the write bit of the mask reset when removing write perms for > >>>>group? Is this really intended? > >>> > >>> > >>>Yes, it is intended, whether it was a good idea or not. > > > > > > [dd] > > > > > >>Very sad :-( It really seems to be impossible to implment something like > >>a "Group Manager" enabling me to delegate priviliges for a group of > >>users to some non-root person. > > > > > > What OS allows you to do it? > > > I have done such things with OpenVMS. Dunno how much control > Windows/NTFS allows. Doesn't OpenVMS also have the concept of default ACLs on directories? How is the matter handled there? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru From owner-freebsd-fs@FreeBSD.ORG Wed Oct 19 08:01:29 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B7FA16A41F; Wed, 19 Oct 2005 08:01:29 +0000 (GMT) (envelope-from rebehn@ant.uni-bremen.de) Received: from antsrv1.ant.uni-bremen.de (antsrv1.ant.uni-bremen.de [134.102.176.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFF3F43D46; Wed, 19 Oct 2005 08:01:28 +0000 (GMT) (envelope-from rebehn@ant.uni-bremen.de) Received: from bremerhaven.ant.uni-bremen.de ([134.102.176.10]) by antsrv1.ant.uni-bremen.de with esmtp (Exim 4.54 (FreeBSD)) id 1ES8t5-0002YJ-Ab; Wed, 19 Oct 2005 10:01:27 +0200 Message-ID: <4355FD57.3060102@ant.uni-bremen.de> Date: Wed, 19 Oct 2005 10:01:27 +0200 From: Heinrich Rebehn User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050831 Debian/1.7.8-1sarge2 X-Accept-Language: en MIME-Version: 1.0 To: Victor Sudakov References: <434F4FF8.9050903@ant.uni-bremen.de> <20051014064145.GA40856@admin.sibptus.tomsk.ru> <434F9DAE.6070607@ant.uni-bremen.de> <20051014134820.GA43849@admin.sibptus.tomsk.ru> <20051014203021.L66014@fledge.watson.org> <435351F7.10101@ant.uni-bremen.de> <20051017141609.GA83692@admin.sibptus.tomsk.ru> <4354D850.8060908@ant.uni-bremen.de> <20051018112135.GA94670@admin.sibptus.tomsk.ru> <4354E644.7090608@ant.uni-bremen.de> <20051018154627.GB95892@admin.sibptus.tomsk.ru> In-Reply-To: <20051018154627.GB95892@admin.sibptus.tomsk.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Robert Watson Subject: Re: Problem with default ACLs and mask X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2005 08:01:29 -0000 Victor Sudakov wrote: > Heinrich Rebehn wrote: > >>>>>>Why is the write bit of the mask reset when removing write perms for >>>>>>group? Is this really intended? >>>>> >>>>> >>>>>Yes, it is intended, whether it was a good idea or not. >>> >>> >>>[dd] >>> >>> >>> >>>>Very sad :-( It really seems to be impossible to implment something like >>>>a "Group Manager" enabling me to delegate priviliges for a group of >>>>users to some non-root person. >>> >>> >>>What OS allows you to do it? >>> >> >>I have done such things with OpenVMS. Dunno how much control >>Windows/NTFS allows. > > > Doesn't OpenVMS also have the concept of default ACLs on directories? > How is the matter handled there? > Yes, it has. But it does not have the concept of a "mask", which limits the resulting access rights. In OpenVMS, group members can also "lock out" the group manager by removing the ACLs. But they must do so on purpose, and the group manager can talk to them if that happens. With Posix1e however, users can inadvertently create directories with the group write bit removed (by extracting a tar ball), which the group manager is then unable to delete. --Heinrich From owner-freebsd-fs@FreeBSD.ORG Wed Oct 19 16:23:14 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 048F416A41F; Wed, 19 Oct 2005 16:23:14 +0000 (GMT) (envelope-from cel@citi.umich.edu) Received: from citi.umich.edu (citi.umich.edu [141.211.133.111]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86BCA43D46; Wed, 19 Oct 2005 16:23:13 +0000 (GMT) (envelope-from cel@citi.umich.edu) Received: from [10.58.53.80] (nat-198-95-226-230.netapp.com [198.95.226.230]) by citi.umich.edu (Postfix) with ESMTP id 3BCA21BAF1; Wed, 19 Oct 2005 12:23:11 -0400 (EDT) Message-ID: <435672EF.3040803@citi.umich.edu> Date: Wed, 19 Oct 2005 09:23:11 -0700 From: Chuck Lever Organization: Network Appliance, Inc. User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <434F4FF8.9050903@ant.uni-bremen.de> <20051014064145.GA40856@admin.sibptus.tomsk.ru> <434F9DAE.6070607@ant.uni-bremen.de> <20051014134820.GA43849@admin.sibptus.tomsk.ru> <20051014203021.L66014@fledge.watson.org> <435351F7.10101@ant.uni-bremen.de> <20051017141609.GA83692@admin.sibptus.tomsk.ru> <4354D850.8060908@ant.uni-bremen.de> <20051018112135.GA94670@admin.sibptus.tomsk.ru> <4354E644.7090608@ant.uni-bremen.de> <20051018154627.GB95892@admin.sibptus.tomsk.ru> <4355FD57.3060102@ant.uni-bremen.de> In-Reply-To: <4355FD57.3060102@ant.uni-bremen.de> Content-Type: multipart/mixed; boundary="------------010301040600080106090008" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org Subject: NAS conference talks on ACL interoperability X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cel@citi.umich.edu List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2005 16:23:14 -0000 This is a multi-part message in MIME format. --------------010301040600080106090008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit yesterday at the NAS Industry conference, there were several talks on ACL interoperability (see http://www.nasconf.com/ for presentation materials). NFSv4 ACL interoperability has issues in three categories: 1. NFSv4 ACLs mapped to and from POSIX mode bits 2. NFSv4 ACLs mapped to and from POSIX-draft ACLs 3. NFSv4 ACLs mapped to and from NTFS/CIFS ACLs it turns out that NFSv4 ACLs can't map cleanly to any of these other access control paradigms, but there is work on standardizing the mapping semantics. one of the presentations was given by the team that just posted the recent IETF draft on NFSv4 ACL mapping. --------------010301040600080106090008-- From owner-freebsd-fs@FreeBSD.ORG Thu Oct 20 20:38:53 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6317716A438 for ; Thu, 20 Oct 2005 20:38:53 +0000 (GMT) (envelope-from ryoon@ipowerweb.com) Received: from svr03.ipowerweb.com (mail.ipowerweb.com [66.235.217.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 15D1843D68 for ; Thu, 20 Oct 2005 20:38:52 +0000 (GMT) (envelope-from ryoon@ipowerweb.com) Received: (qmail 63663 invoked from network); 20 Oct 2005 20:16:12 -0000 Received: from unknown (HELO ?127.0.0.1?) (66.235.206.35) by 0 with SMTP; 20 Oct 2005 20:16:11 -0000 Message-ID: <4358000E.4020805@ipowerweb.com> Date: Thu, 20 Oct 2005 13:37:34 -0700 From: Robert Yoon User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-ipwdcc-2-Metrics: svr03.ipowerweb.com 209; Body=1 Fuz1=1 Fuz2=1 Subject: 4.11 fsck_y_enable="yes" does not work on boot up X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ryoon@ipowerweb.com List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2005 20:38:53 -0000 I have a problem with fsck_y_enable on 4.11. If my server crashes and I have that enabled, its still prompts me to fsck manually. I thought that fsck_y_enable was supposed to automagically fsck -y the partitions. It does on my 4.10 setups but not my 4.11 any possible reason you guys can think of ? I hate having to console in to manually fsck...any tips would be great From owner-freebsd-fs@FreeBSD.ORG Fri Oct 21 08:33:45 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F51616A41F for ; Fri, 21 Oct 2005 08:33:45 +0000 (GMT) (envelope-from rebehn@ant.uni-bremen.de) Received: from antsrv1.ant.uni-bremen.de (antsrv1.ant.uni-bremen.de [134.102.176.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB23343D46 for ; Fri, 21 Oct 2005 08:33:44 +0000 (GMT) (envelope-from rebehn@ant.uni-bremen.de) Received: from bremerhaven.ant.uni-bremen.de ([134.102.176.10]) by antsrv1.ant.uni-bremen.de with esmtp (Exim 4.54 (FreeBSD)) id 1ESsLO-000P0Q-Tm; Fri, 21 Oct 2005 10:33:42 +0200 Message-ID: <4358A7E6.2080708@ant.uni-bremen.de> Date: Fri, 21 Oct 2005 10:33:42 +0200 From: Heinrich Rebehn User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050831 Debian/1.7.8-1sarge2 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-fs@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Help needed for hacking the acl mask X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 08:33:45 -0000 Hi all, Since we do need usable acls here at work, i decided to go for a quick and dirty hack. Can someone point me to the code location(s) where the acl mask is overwritten? I already found sys/kern/kern_acl.c and changed it so that the mask is ORed with the create mode. This works for newly created files,regardless of the umask setting. However, chmod g-w still resets the write bit of the acl mask. I thought this was handled in lib/libc/posix1e/acl_calc_mask.c, but it does not seem to be called by chmod(1). Some questions: - Where do i have to look further? - If i make changes to libc, do i have to do a "make installworld" or will a "make install" in lib/libc be enough? - Is there a tutorial on debugging/walking through libc? Thanks for any hints, Heinrich -- Heinrich Rebehn University of Bremen Physics / Electrical and Electronics Engineering - Department of Telecommunications - Phone : +49/421/218-4664 Fax : -3341 From owner-freebsd-fs@FreeBSD.ORG Fri Oct 21 10:40:38 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DB8816A41F for ; Fri, 21 Oct 2005 10:40:38 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E62D43D48 for ; Fri, 21 Oct 2005 10:40:37 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5193446C47; Fri, 21 Oct 2005 06:40:37 -0400 (EDT) Date: Fri, 21 Oct 2005 11:40:37 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Heinrich Rebehn In-Reply-To: <4358A7E6.2080708@ant.uni-bremen.de> Message-ID: <20051021111734.O81085@fledge.watson.org> References: <4358A7E6.2080708@ant.uni-bremen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org Subject: Re: Help needed for hacking the acl mask X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2005 10:40:38 -0000 On Fri, 21 Oct 2005, Heinrich Rebehn wrote: > Since we do need usable acls here at work, i decided to go for a quick > and dirty hack. Can someone point me to the code location(s) where the > acl mask is overwritten? > > I already found sys/kern/kern_acl.c and changed it so that the mask is > ORed with the create mode. This works for newly created files,regardless > of the umask setting. My impression, although I haven't investigated in a year or two, is that it actually should be a little more complicated than this if you want to run with the Solaris mask semantics. Specifically, the problem is that the umask has already masked application-requested creation bits by the time cmode is passed to acl_posix1e_newfilemode(), so all you can do there is decide not to impose the ACL mask, whereas to get the Solaris semantics you want to impose the ACL mask but not the umask. Correcting this is fairly complicated, as it requires that acl_posix1e_newfilemode() gain access to the original requested mode from the system call, which is normally not passed to the file system VOP, it's actually evaluted in the high level system call code before even entering the file system code. When I last left off exploring a solution, I concluded that what I wanted to do was pass the process umask and process requested mode into all VOP's that create objects, rather than the post-processed creation mode. Then this would be passed into acl_posix1e_newfilemode(), and depending on the presence of ah ACL mask entry in the parent default ACL, acl_posix1e_newfilemode() could then decide whether or not to incorporate the umask or not. This turned out to be further complicated by the fact that the combination of the umask and system call creation mode was performed in a way sensitive to the type of object and method of creation. Different system calls mask or ignore different additional bits (such as the sticky bit) depending on the object type. This left me with a todo item of determining if this was correct or not, and I didn't have a chance to follow up at that point. However, looking at the above, it requires making modifications to the file system VFS interface, each file system, etc, and so I moved on to other more pressing issues that had to be addressed. > However, chmod g-w still resets the write bit of the acl mask. I thought > this was handled in lib/libc/posix1e/acl_calc_mask.c, but it does not > seem to be called by chmod(1). This is because, according to POSIX.1e, the file permission bits are in fact simply a subset of the ACL, not an additional set of values that are evaluated as well as the ACL. The confusing thing about the POSIX.1e ACL behavior with chmod() and stat() is how this is done: the answer is that it depends on whether or not there is an ACL_MASK entry. If there is no ACL mask entry, the owner, group, and other fields in the mode override the ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER entries in the ACL. However, if there is a mask entry, they respectively override the ACL_USER_OBJ, ACL_MASK, and ACL_OTHER entries. The idea being that if you have an extended acl, the group bits in the requested mode change will mask all non-owner and non-other entries in the ACL. This is discussed in detail in POSIX.1e, and is a feature present in all POSIX.1e or POSIX.1e-like implementations I'm aware of. This allows an application that doesn't understand ACLs to conservatively change the file mode. The implementation of this is somewhat complicated, so I draw your attention to two functions in the UFS ACL code: ufs_sync_acl_from_inode() - the mode field on the inode has changed, and the ACL entries should be synchronized to it. ufs_sync_inode_from_acl() - the ACL on a file has been changed, and the inode mode should be updated. You'll see that in ufs_chmod(), the two are not resynchronized: this allows the ACL fields to be stale with respect to the inode mode field. This is rectified later because when the ACL is pulled off the disk or out of the buffer cache by ufs_getacl(), it calls ufs_sync_acl_from_inode() to update those fields. This avoids chmod() resulting in an extended attribute write, which is quite expensive. It also helps in the implementation of optimizations that avoid storing an ACL for a file if no ACL has been put on the file. If you're looking to change how chmod() and ACLs interact, you'll need to think very carefully about the implications in this context. Off hand, I'm not sure the exact details of what you want to change will be -- you will probably, among other things, need to change how ACLs are re-synchronized to the inode mode when the ACL is read from the disk -- you might find that you do need to write out a new ACL when chmod() occurs, or that you can use the same inconsistency optimization I describe above but with a slightly different implementation. The other thing to be aware of is that POSIX.1e (programmatic interfaces) and POSIX.2c (user commands) provide slightly different semantics for the user, so if you're used to the way the setfacl command works, the underlying APIs that implement it are a bit different. Specifically, setfacl has the notion that the mask is reculculated automatically based on the change -- this is purely a property of the user application. The kernel has no notion of recalculating the mask based on changes to ACL fields, with the exception that the mask is modified by chmod(). Much of the weirdness in POSIX.1e ACLs is a property of trying to continue to offer file mode semantics in a conservative way so that applications see what they expect even if they don't support ACLs -- for example, that if they chmod() a file, stat() will show the expected resulting mode, and "something useful" will happen to the ACL as a result. I don't make any claim that this is optimal from a user perspective in the presence of applications that do understand ACLs. The only real modification to mode/ACL semantics I've been considering is the change in umask operation, as described above, and implemented in Solaris and Linux. In the past, it has been observed that even minor tweaks in ACL/mode interaction can result in security vulnerabilities, usually due to violating user or application assumptions, and so I advise a lot of caution :-). Robert N M Watson From owner-freebsd-fs@FreeBSD.ORG Sat Oct 22 22:16:37 2005 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B88916A41F for ; Sat, 22 Oct 2005 22:16:37 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from S4.cableone.net (s4.cableone.net [24.116.0.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27FEC43D45 for ; Sat, 22 Oct 2005 22:16:36 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from vixen42.vulpes (unverified [24.119.122.41]) by S4.cableone.net (CableOne SMTP Service S4) with ESMTP id 34588629 for ; Sat, 22 Oct 2005 14:29:50 -0700 Date: Sat, 22 Oct 2005 16:20:26 -0500 From: Vulpes Velox To: freebsd-fs@freebsd.org Message-ID: <20051022162026.59e66eb6@vixen42.vulpes> X-Mailer: Sylpheed-Claws 1.9.15 (GTK+ 2.6.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IP-stats: Incoming Last 1, First 155, in=280, out=0, spam=0 X-External-IP: 24.119.122.41 X-Abuse-Info: Send abuse complaints to abuse@cableone.net Subject: newfs_msdos oddity X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2005 22:16:37 -0000 Running into one odd problem with Windows 2000. Apparently Windows 2000 can read and install to a partition formated with FAT32 by FreeBSD, but it can't boot it. Any one seen any thing odd like this before or have any suggestions? I am installing it to a secondary drive in that box.