Date: Tue, 27 Jun 2006 16:53:02 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "M. Warner Losh" <imp@bsdimp.com> Cc: gurney_j@resnet.uoregon.edu, pjd@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: Accessing disks via their serial numbers. Message-ID: <62122.1151427182@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 27 Jun 2006 10:33:43 CST." <20060627.103343.-432837786.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20060627.103343.-432837786.imp@bsdimp.com>, "M. Warner Losh" writes : >: devfs is not a hardware inventory facility, it is magic place for >: performing a rendez-vous with a device driver. > >True, but somewhat irrelvant. Not really, it has to be kept in mind to avoid decending into the hell currently reserved for Linux procfs :-) >True, but somewhat irrelvant. This does not go to the question that I >asked. What problems does having fully enumerated devices cause? There is no problem with fully enumerated devices, as long as they don't cause an explosion in the number of devices. >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. The problem is that it exactly doesn't do that, and can't possibly do that, because hardware is not seen by devfs until the driver is loaded. I realize that this sounds a bit Clintonesque, but it all comes down to what your definition of "available" is. For instance, the crypt-hw support has one joint device node in /dev but can cover up 16 cards, without ever disclosing to you what they are or what they can do, until you open the joint device and ask with the right ioctls. >There are other facilities for finding out the >underlying hardware, but there's no way to find the magic names in >/dev easily. Only whatever convention we decide to use to pick the names them can help you there. >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. You lost me there... >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 have the devfs(8) rules for 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? We generally have that. The only exceptions I'm aware of right now are pseudo devices, for which precreation doesn't make sense at all. >My big problem with magic files and hiding them is that it becomes >difficult or impossible to diagnose and troubleshoot. I have a very big problem with magic files as well. Currently g_label doesn't impose any restrictions on the label strings of the device, which means that you can include '/', '..' and ';' in labels. I don't need to tell you what that means for shell scripts etc. Put a g_label on an USB key and trick the admin into to doing something stupid and you're all set: just type mount -t msdos /dev/da0* I can't remember which slice it is... The reason why I am advocating using "on-demand" names for what Pawel is proposing is that way the names only exist if people ask for them, and only the names they ask for exists. In addition to avoiding a wanton doubling of the geom mesh size (because he does it at the very bottom) that also adds significant flexibilty and security to the table. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?62122.1151427182>