Date: Sat, 10 Feb 1996 00:33:54 -0600 (CST) From: Kent Hamilton <kenth@HNS.St-Louis.Mo.US> To: julian@ref.tfs.com (Julian Elischer) Cc: jkh@time.cdrom.com, terry@lambert.org, current@FreeBSD.org Subject: Re: FS PATCHES: THE NEXT GENERATION Message-ID: <199602100633.AAA00595@gwydion.hns.st-louis.mo.us> In-Reply-To: <199602092020.MAA00264@ref.tfs.com> from "Julian Elischer" at Feb 9, 96 12:20:09 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > hmm but devfs might be compulsory :) > > > I'm joking until I figure a way around the persistance problem > personally I'll be using a kernel that will disable the use of devices > on all kinds of filesystems other than devfs. > > Actually I think persistance is not a real problem, it's a PR excersize > We're getting creamed by NT which doesn't have permissions persistance. > I think a utility that allows the admin to tune the permissions of devices > will make the screams go away. > > basically a little menu system similar to what you use in the > install system. > as output it produces a littel file called devs.rc that is run at boot. I've never seen the proposal for this stuff (I only subscribe to -current)... so I may be way off on my understanding of what we are talking about, but... I'll still toss in my two sense :-) Where can I find a copy of the proposal for this anyway? I am a sysadmin for a company and we use a couple of FreeBSD systems currently. If I change a device file then there was a damn good reason for it and I want it to still be that way when the system re-boots. I *don't* want to have to wade through YACMS (Yet Another Cute Menu System) to have to make those changes stick either. I *do* really like the entire idea behind devfs and if there is a way to make it stick across boots, etc. that doesn't require my having to take extra steps to do it then I'd be happy to see it. [deleted] > > > > It has to work the way it works now, e.g. you should be able to just > > walk into /dev (and that could be one of many incarnations of `dev', > > remember) and futz with permissions or "delete" device entries you > > don't want to be present for security reasons, and that information > > should stay there across mounts. > > I disagree about this. I *strongly* disagree with you. If I change the dev's on my firewall I expect 'em to damn well stay changed and the first time they don't I first go searching for the person that hacked the firewall, then finding nothing, I dump it and rebuild it from scratch assuming that I've just been badly beaten at my game. Now you tell me that they won't stay that way? I dump it and get a new o/s. > I'd suggest a seprate utility to allow this to be done REALLY EASILY. > One possibility I thought about was a user-land daemon that > scans the directory every now and then (cron?) > and notices changes.. alternatively there could be syslog option to > send messages from the device filesystem out to some sort of log > that get's replayed on bootup. I could live with a cron job that scans for changes and records 'em. > I personally don't think it's a problem except in the minds of those > who are stuck in the past. Things need to change. > > 1/ major numbers need to become dynamic > 2/ devices shouldn't exist without their /dev/entries > 3/ devices shouldn't exist with the WRONG /dev/entries > 4/ /dev/entries with no corresponding device is also bogus > 5/ minor numbers need to become dynamic for some device types > 6/ devices need to be able to change their representation on the fly > > given this I don't see how there can be another answer, except for > something that can pass through the sysctl interface and pull out all the > minor numbers. That would be I think an ugly answer but one some-one else > is welcome to try. > > Anyone who wants full persistance is welcome to > use the old system and try work out what minor numbers are valid for the > disk slices on the fly. I'd agree that things need to change, *but* not at the expense of my ass. If I don't feel the system is going to be secure because of the changes then it's real simple. I won't use it. Also, just curious, how do you plan to handle any applications like, as an example, Informix OnLine which expect to be handed a raw partition (slice) owned by informix.informix mode 660 and won't work unless it get's it. Call it a "legacy app" and forget it? (And yes I know it doesn't apply to FreeBSD, but who knows.... I've run the "Standard Engine" version on FreeBSD under the IBCS emulator and it worked for my *really* limited testing, had to swipe a couple libraries from a SCO box as I recall though.) Anyway I hope I didn't miss the point of this whole thing tooooo badly. -- Kent Hamilton Work: KHamilton@Hunter.COM URL: http://www.icon-stl.net/~khamilto Play: KentH@HNS.St-Louis.Mo.US
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602100633.AAA00595>