From owner-freebsd-fs@FreeBSD.ORG Fri Oct 14 12:51: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 4196916A41F; Fri, 14 Oct 2005 12:51:53 +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 A60CD43D45; Fri, 14 Oct 2005 12:51:52 +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 1EQP2N-000Fyk-3c; Fri, 14 Oct 2005 14:51:51 +0200 Message-ID: <434FA9E6.9070009@ant.uni-bremen.de> Date: Fri, 14 Oct 2005 14:51:50 +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> <20051014092250.D66245@fledge.watson.org> In-Reply-To: <20051014092250.D66245@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: Fri, 14 Oct 2005 12:51:53 -0000 Robert Watson wrote: > > On Fri, 14 Oct 2005, Victor Sudakov wrote: > >> Heinrich Rebehn wrote: >> >>> >> >> [dd] >> >>> Am i doing something wrong here? Why is the mask not propagated? >> >> >> I am afraid the current umask prevents it. You must set it to >> something like "umask 002" before you create your files or directories >> (the group write bit matters here). > > > The problem, so to speak, is that we actually implement what is > described in the POSIX.1e spec. When we did our initial implementation, > the various OS's varied a bit in the semantics they implemented: > > - Solaris implemented umask override if the mask was specified in the > default ACL. does umask override or is umask overriden? :-) I suppose the former. > - IRIX implemented the spec. > > Since that time, Linux has turned up and implemented the Solaris model, > and IRIX has switched to the Solaris model also as a result of peer > pressure. I've previouly looked at switching us, but it tears up our > kernel APIs some and will require significant testing. I had hoped to > do this for FreeBSD 6.x but was derailed working on other problems that > needed to be fixed. My hope is to change the default in FreeBSD 7.x. > Doing this requires: > > (1) All file creation VOP's to accept different fields -- rather than > accepting the completed creation mode, they need to accept the > creation mask and requested creation mode. > > (2) The fairly dispersed current logic for combining the umask and > requested creation mask needs to be discovered, normalized, and > documented. You'll notice if you grep around that the umask + > creation mode processing uses slightly different bit combination and > masking operations depending on object type. Only code inspection > combined with some portability testing will tell us if what's there > now is a bug or a feature. > > (3) Addition of logic to kern_acl.c so that file systems implementing > POSIX.1e can ask the revised question about initial ACL and file mode. > > (4) Much testing. Ideally, creastion of fairly extensive regression tests > having to do with the modes of files on creation, ACLs, etc. > > There's also been a recent discussion on trustedbsd-discuss about > implementing alternative semantics based on the NFSv4 ACL model. I've > taken a walk through the spec and a bit of initial hacking, and need to > send e-mail to the NFSv4 working group mailing list asking for > clarification of some points. If we did do this, we would presumably > add a new flag, nfsv4_acl, for UFS, to allow the administrator to select > one of two models. A further complexity is that these models are > require different, and so we'd have to look carefully at tools and > application behavior. > > Robert N M Watson Thanks for this in-depth explanation. This sounds like we cannot expect a solution any time soon. I will think about another method of managing our lab users (or use adjust umask - better than nothing). I would really appreciate alternative models for NFS4. --Heinrich