[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Hurd FS hierarchy (was Re: LD_LIBRARY_PATH troubles)

From: Richard Kreuter
Subject: Re: Hurd FS hierarchy (was Re: LD_LIBRARY_PATH troubles)
Date: Sun, 17 Mar 2002 17:43:09 -0500
User-agent: Mutt/1.3.27i

On Sun, Mar 17, 2002 at 09:36:02PM +0100, Jeroen Dekkers wrote:
> On Sun, Mar 17, 2002 at 03:31:16PM -0500, Richard Kreuter wrote:
> >
> >   "On a GNU system, the contents of a directory listing need not
> > reside on a single volume; therefore directories may be created in
> > the root directory of a system, though the size of the bootstrap
> > filesystem should be kept to a minimum."
> I don't see why that should be. If somebody wants to have everything
> on one partition he should just do that. The bootstrap filesystem
> can also be a cd-rom or DVD for example, which are quite big.

  I didn't word that correctly.  I'll see if I can make my meaning

> >   I assume I'm using the term 'bootstrap filesystem' correctly here.
> > Is this term acceptable for policy use?
> I'm not sure it's better than "root filesystem".

  Sometimes the term 'filesystem' means 'hierarchy of files (as in
"the /usr filesystem")'; sometimes it means 'store containing some
files' (as in "/dev/hd0s9 is my root filesystem"); sometimes it means
'filesystem format' (as in "Second Extended Filesystem").  The first
two being relevant options here, the term "root filesystem" here might
mean "the hierarchy of files in the root directory" or maybe "the disk
partition containing the files needed to boot and restore the system",
and these two won't need to be the same thing.  The FHS doesn't
distinguish these because Linux doesn't offer a unionfs, I guess.

  Some people might want to keep their bootstrap/recovery files on a
separate store, for the reasons provided in the rationale in FHS 3.1.
Presumably, we don't want a system that makes this impossible, right?

  Perhaps I'm not understanding how shadowfs will work.  Suppose the
root directory contains the union of files on stores a and b.  Will
the administrator be able to decide, e.g., that write operations
intended for /usr all go to store b, and otherwise they go to store a?

> Yes, that was my meaning. I don't see why static linked binaries must
> have .static, it's only a good practice to do so.


> I think all server binaries should go in /hurd.

  Yes, though servers written by unprivileged users can't be put
there, as a rule.

  Also, there's the possibility that site administrators might want to
distinguish servers provided by the distributor from third-party ones.
Shouldn't the latter be put someplace else (a different store, and
maybe a different directory), in principle?

  <Slightly offtopic> There is also the possibility of 'malicious
servers', say, a server that tries to remove the files in the owner's
home directory when it starts up.  Suppose a tarfs that honors
translator settings in arbitrary archives; then looking at a
filesystem presentation of an archive that contains such a malicious
server and a node with that server set on it will be pretty
unpleasant.  One mechanism to reduce the possibility for this is a
policy for distinguishing 'trusted servers'; maybe /hurd should only
contain these.  Just a thought.

> Binaries, libraries and manpages should just go in /usr/bin, /usr/lib
> and /usr/man. Only for include it should be /usr/include/X11 to make
> #include <X11/foo.h> possible. Debian policy should do what the FHS
> says, not the other way around.

  Yes, sorry; I misread the Debian policy here.  

Richard Kreuter

reply via email to

[Prev in Thread] Current Thread [Next in Thread]