From owner-freebsd-current@FreeBSD.ORG Mon Sep 26 22:38:53 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 795ED1065670; Mon, 26 Sep 2011 22:38:53 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id 03C938FC15; Mon, 26 Sep 2011 22:38:52 +0000 (UTC) X-AuditID: 12074422-b7ff56d00000092f-6f-4e80fefbd2a7 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id F6.7A.02351.BFEF08E4; Mon, 26 Sep 2011 18:38:52 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p8QMcpGP009788; Mon, 26 Sep 2011 18:38:51 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p8QMcn6A006205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Sep 2011 18:38:50 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p8QMcntC021610; Mon, 26 Sep 2011 18:38:49 -0400 (EDT) Date: Mon, 26 Sep 2011 18:38:49 -0400 (EDT) From: Benjamin Kaduk To: Brett Glass In-Reply-To: <201109262035.OAA17199@lariat.net> Message-ID: References: <201109260053.SAA25795@lariat.net> <201109260927.02540.jhb@freebsd.org> <201109262035.OAA17199@lariat.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixCmqrfvnX4OfwaPZLBZzvvxjtZjz5gOT xd4j15kdmD1mfJrP4nHllUkAUxSXTUpqTmZZapG+XQJXxt8f3SwFH6Qqvi3extjAeEO0i5GT Q0LAROL9uplsELaYxIV764FsLg4hgX2MEs1rlrJDOBsYJa4tvw+VOcAk8aizkRHCaWCUOPp9 EiNIP4uAtsSN1y/BZrEJqEjMfLMRzBYRUJK4vegtcxcjBwezgL3E9pc8IGFhAX2J4w0/mUFs TiD71s6f7CA2L1DJ1os9TBDzVzFKLDy+jwUkISqgI7F6/xQWiCJBiZMzn4DZzAKWEuf+XGeb wCg4C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbqmermZJXqpKaWbGEFBy+6itIPx 50GlQ4wCHIxKPLwztzX4CbEmlhVX5h5ilORgUhLlff0bKMSXlJ9SmZFYnBFfVJqTWnyIUYKD WUmE1/Q1UI43JbGyKrUoHyYlzcGiJM7LtdPBT0ggPbEkNTs1tSC1CCYrw8GhJMHbAIxOIcGi 1PTUirTMnBKENBMHJ8hwHqDhZSA1vMUFibnFmekQ+VOMilLivD4gCQGQREZpHlwvLKm8YhQH ekWY1xOkigeYkOC6XwENZgIanFNTCzK4JBEhJdXAOOdjyW2BI4V+C+QcMj2Fne8KvM1YpGSx MO3txtIXWnlLFzY2sExmy+gP3nhWzPfBxYWno9I5lRSsX5YoZmQ/mfKZyXuiZPFBh+1/gop9 26tZeOfZPX/jvW7WFscDqkn9S66ctBH8wGxo/OyLQZGo8Pu2O48e6IWcvLzDpvljc/r3G6uk Y5L8lFiKMxINtZiLihMB72LQZwUDAAA= Cc: freebsd-current@freebsd.org Subject: Re: Experiences with FreeBSD 9.0-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 22:38:53 -0000 On Mon, 26 Sep 2011, Brett Glass wrote: > At 12:03 PM 9/26/2011, Benjamin Kaduk wrote: > >> On Mon, 26 Sep 2011, John Baldwin wrote: >> >>> I can't speak to the "one-big-fs" bit (there was another thread long ago >>> about >>> that). However, as to the partitioning bit, bsdinstall is defaulting to >>> using >> >> The question of how to layout and split filesystems was discussed at the >> filesystems working group of the devsummit at BSDCan this may. >> (http://wiki.freebsd.org/201105DevSummit/FileSystems down to "Filesystem >> Layout" near the bottom) Though "one big root" did not garner a huge >> amount of support, neither were there particularly compelling arguments >> against it (if I remember correctly). It's certainly easier to write an >> autopartitioner for, so I don't really blame Nathan for having chosen it >> initially. > > My personal preference would be to place portions of the directory tree which > contain critical configuration information and are not written in normal use > -- e.g. /etc and /boot -- in one or more separate partitions. This would make > it possible to mount them read-only unless the system configuration was being > changed, new software was being installed, or a new kernel was being > generated. This would protect them not only from malicious tampering but also > from being scrambled by buggy userland software. And since it would not be > written during normal operation, it would survive 100% intact even if > journaling and/or serialization of metadata updates (e.g. softupdates) were > to fail. > > Unfortunately, due to past history, /usr is mixed-use. It normally contains > both configuration information -- e.g. /usr/local/etc -- and more volatile > data such as users' home directories. This prevents /usr/local/etc, which > also contains mission-critical configuration information, from being > protected if you just protect /. Some proprietary Unices have fixed this > historical flaw in the traditional hierarchy by moving /usr/local/etc to > another location and them symlinking it back to where seasoned administrators > expect it to be, thus honoring POLA. The three open source, old school BSDs > (Free, Net, Open) have not done this to date, but it's something that should > be considered in the long run. It would certainly make the creation of > embedded systems easier, as well as enhancing security in multi-user systems! > > If I wrote an installer, my preference would be to have it create one > partition that contained critical configuration information and software (and > could be mounted read-only) and one that contained the rest of the usual > directory tree (and could be mounted read-write). It could do the symlinking > trick mentioned above to bring parts of /usr over to the read-only > administrative partition. The only cleanup task that would remain would be to > make sure that no ports were configured to place their logs, pid files, etc. > in directories such as /usr/local/etc. (Most already do not.) There was also general sentiment that the rise of ZFS would allow just this sort of fine-grained partitioning, which is a huge advantage of its ability to create datasets on the fly. This perception that ZFS is most of the future probably contributed to the lack of strong opinions regarding the default UFS partition scheme. -Ben Kaduk