Date: Tue, 27 Jun 2006 18:43:19 +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: <62426.1151433799@critter.freebsd.dk> In-Reply-To: Your message of "Tue, 27 Jun 2006 12:04:24 CST." <20060627.120424.-1625880159.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20060627.120424.-1625880159.imp@bsdimp.com>, "M. Warner Losh" write s: >In message: <62122.1151427182@critter.freebsd.dk> > "Poul-Henning Kamp" <phk@phk.freebsd.dk> writes: >: There is no problem with fully enumerated devices, as long as >: they don't cause an explosion in the number of devices. > >That's my view as well! We agree! Well, not quite, but lets leave the deep UNIX philosophy questions behind for a moment. >: We have the devfs(8) rules for that. > >And no way to audit them. The basic problem that I'd have in this >specific case (serial numbers ala some variation of /dev/ad/ABCDEFG) >is that the system administrator cannot set and verify the permissions >of the filename. My take on this is different than yours. I don't think we should allow names that are not "under control", and by not "under control" I mean device names which the device driver writer doesn't control or at the very least sanitize. For instance, if you want to create names that match random strings, like the tape labels in your robot, the sensible and security concious device driver writer makes sure the names have a unique prefix: /dev/tape/$label or similar, so that devfs(8) rules can be written in a surefire way. >A simple fix to this would be to have a sysctl that says to filter or >allow magic characters in the label name. I really don't think it should be optional. A vis(3) in some form should always happen. >: 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. > >Making them on-demand makes it impossible to audit. Right now, if I'm >owrried abotu disk security, I can do: That is why I'm not terribly keen on any kind of user-controlled /dev filenames. >: 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. > >However, I'm not sure I understand the >flexibility and security side of things. Properly written and >implemented, I'm not sure how it affects security. With an on-demand scheme, the scalability issue disappears, so we can add hard labels, soft labels, physical position (bus:id:lun), OEM labels, anything you can think off. With a fully enumerated scheme, the scalability bites hard. The only way to collapse these two views would be to allow drivers to register directories in DEVFS, so that they get to enumerate the issue when necessary, but without allocating cdevs for all the unnessesary nodes. That is heading straight down the Linux procfs path. If we want to go that way: fine, personally I think it leads to madness. And please remember: This entire thing only comes up because Pawel doesn't want to solve the problem correctly for g_label, this is the fall-back "quick&dirty" solution. The correct solution is to give the users a reliable tool for stealing the necessary labelsector from the end of a filesystem. -- 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?62426.1151433799>