From owner-freebsd-current@FreeBSD.ORG Thu Apr 12 18:12:23 2007 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26E4D16A401; Thu, 12 Apr 2007 18:12:23 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id BF86F13C4B7; Thu, 12 Apr 2007 18:12:22 +0000 (UTC) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id l3CICLx7057972; Thu, 12 Apr 2007 20:12:21 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [10.1.1.14]) by cicely5.cicely.de (8.13.4/8.13.4) with ESMTP id l3CIC5dT037412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2007 20:12:06 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.13.4/8.13.3) with ESMTP id l3CIC5Hn035505; Thu, 12 Apr 2007 20:12:05 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.13.4/8.13.3/Submit) id l3CIC5xA035504; Thu, 12 Apr 2007 20:12:05 +0200 (CEST) (envelope-from ticso) Date: Thu, 12 Apr 2007 20:12:05 +0200 From: Bernd Walter To: Kris Kennaway Message-ID: <20070412181204.GC30772@cicely12.cicely.de> References: <200704112004.03903.lists@jnielsen.net> <20070412021645.GQ30772@cicely12.cicely.de> <20070412114135.C64803@fledge.watson.org> <20070412172811.GA48309@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070412172811.GA48309@xor.obsecurity.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.4-STABLE alpha User-Agent: Mutt/1.5.9i X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on cicely12.cicely.de Cc: John Nielsen , Robert Watson , ticso@cicely.de, current@FreeBSD.org Subject: Re: ZFS to support chflags? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2007 18:12:23 -0000 On Thu, Apr 12, 2007 at 01:28:11PM -0400, Kris Kennaway wrote: > On Thu, Apr 12, 2007 at 11:42:37AM +0100, Robert Watson wrote: > > > > On Thu, 12 Apr 2007, Bernd Walter wrote: > > > > >On Wed, Apr 11, 2007 at 08:04:03PM -0400, John Nielsen wrote: > > > > > >>I just moved /usr over to a zpool on my -CURRENT system. Performance and > > >>stability are both excellent so far. (Thanks Pawel!) However I noticed > > >>that setting FS flags on files with chflags is not supported. Would it be > > >>feasible to add support for flags on ZFS, and if so are there plans to do > > >>so? > > >> > > >>If not (and/or in the meantime), are there any places in the base system > > >>where flags are required for normal operation? (/var maybe?) > > > > > >Some binaries have such flags set, but it is not required, otherwise > > >diskless NFS wouldn't work. I often see installworld warnings about beeing > > >unable to set extended flags on ld.so and others on my diskless boxes. > > > > I'm not a big fan of setting these flags -- I fairly frequently run into > > problems when I installworld an NFS root on the NFS host, then try to work > > with it over NFS from the NFS-booted system, as the flags can't be removed > > via NFS. They don't offer a security benefit as-installed, and perhaps > > offer a benefit with respect to preventing people from shooting themselves > > in the foot (or perhaps not). > > Yeah, historical intentions notwithstanding, the real benefit of schg > flags on critical pieces is anti foot-shooting. e.g. you really don't > want to accidentally delete ld-elf.so.1 or libc.so.7 or init. > You can usually recover from this, but it can mess up your whole day > :) The idea is obvious, but it's not up to date to be really usefull beside a few special cases. E.g. I don't mind loosing ld-elf.so.1 if mount* and restore are lost as well. On the other hand we have /rescue today - schg would make way more sense there, but it's currently unprotected. -- B.Walter http://www.bwct.de http://www.fizon.de bernd@bwct.de info@bwct.de support@fizon.de