Date: Tue, 27 Jun 2006 10:33:43 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: phk@phk.freebsd.dk Cc: gurney_j@resnet.uoregon.edu, pjd@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Accessing disks via their serial numbers. Message-ID: <20060627.103343.-432837786.imp@bsdimp.com> In-Reply-To: <52322.1151337322@critter.freebsd.dk> References: <20060626.093240.-432837692.imp@bsdimp.com> <52322.1151337322@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <52322.1151337322@critter.freebsd.dk>
"Poul-Henning Kamp" <phk@phk.freebsd.dk> writes:
: In message <20060626.093240.-432837692.imp@bsdimp.com>, "M. Warner Losh" writes
: :
:
: >: I suspect that the proponents of this scheme will object to my proposal
: >: because they can not do a "ls /dev/mumble/*" to get a list of disk
: >: serial numbers[...]
: >
: >I'm curious... what's wrong with adding additional things to the /dev
: >directory? One of the biggest annoyances I have in troubleshooting is
: >not being able to see what files are there and having magic file names
: >that one can open but not list.
:
: devfs is not a hardware inventory facility, it is magic place for
: performing a rendez-vous with a device driver.
True, but somewhat irrelvant. This does not go to the question that I
asked. What problems does having fully enumerated devices cause?
devfs does allow directory listings, therefore absent some compelling
reason to the contrary these listings should be complete. This is an
enumeration of the available devices, which closely mirrors the
available hardware. There are other facilities for finding out the
underlying hardware, but there's no way to find the magic names in
/dev easily. While it is a magic place, that magic place exists in
the context of a file system, and file systems aren't supposed to
randomly open files.
It is also a security concern. If I wanted to have non-default
permissions on these magic nodes, at the very least I'd have no way to
audit them. I'm unclear if doing the normal unix operations on the
magic nodes would suffice.
: We really do not want to prepopulate /dev with all possible devices,
: that model broke down in the late 1980ies and it has not become more
: feasible in the meantime.
You are arguing apples and oranges here. The fully enumerated /dev
with all possible device entries based on what the machine might
possibly have is not what I'm asking. We all know there are issues
with that. My question is more specific. What is wrong with having
entries in devfs of files you can actually open, when we know the
universe that is possible given the current knowledge of the kernel?
Why have some of them hidden and some of them present? Why subject
the user to the hassles that having hidden, magic files causes?
: The reason people have trouble understanding this very basic point is
: that UCB strayed from the UNIX philosophy when they added all the socket
: system calls instead of adding the /net filesystem.
Again, you are comparing apples to oranges. The current local node
cannot know the list of possibilities for nodes on the network. In
the specific case that I'm asking about, we do know the possibilities.
The number of entries, even on a large system, is relatively small.
: If we had /net, everybody would be able to see that non-storage filesystems
: should not be prepopulated with every conceiveable vnode.
This is true, but irrelevant. There are different design
considerations for different types of virtual file systmes.
: The automounter is another good example: here quite complex software
: was written specifically to avoid prepopulation with all conceiveable
: vnodes and mountpoints, that that is even for storage filesystems.
This is a bug in the automounter, and has been for a very long time.
I've always hated it.
My big problem with magic files and hiding them is that it becomes
difficult or impossible to diagnose and troubleshoot. They can create
security problems, especially if there's no way to audit their
existance and attributes. If there's a real, compelling reason to
hide the files, I might understand. But so far I've seen no real,
compelling reason proffered as to why the kernel can't expose the
knowledge that it has in this manner.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060627.103343.-432837786.imp>