Date: Sat, 10 Feb 1996 16:52:03 -0800 (PST) From: Julian Elischer <julian@ref.tfs.com> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, KentH@HNS.St-Louis.Mo.US, current@FreeBSD.ORG Subject: Re: FS PATCHES: THE NEXT GENERATION Message-ID: <199602110052.QAA05129@ref.tfs.com> In-Reply-To: <29143.823998441@time.cdrom.com> from "Jordan K. Hubbard" at Feb 10, 96 04:27:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I put it to you that security of devices is such an important thing that you don't want persistance of device ownerships I think that device ownerships should be set upaccording to a STATED POLICY on the matter. A hacker who manages to change the ownership od a device should not find his change still in place after a reboot. All automatic methods I can think of do not differntiate between a malicious or legitimate cahnging of permissions information. A POLICY method can take into account new devices where persistance methods can not handle a device that does not yet exist. I think that having entries for devices not yet present is one of the things I'm trying to get away from... batteries nearly dead.. going offline soon. julian > > I see no philosophical difference from one administrative override > > that modifies the default kernel and another that modifies the > > same file, but operates on different data. > > Neither do I, but no proposal so far has covered a mechanism which > would make the maintainance of this data automatic. In the case of > dset, it's one line which *we* added, and most users don't even _know_ > or care about dset, they just know their UserConfig changes are > automagically saved somehow, which is how it should be. > > Implement a mechanism as user-transparent as dset for /dev persistance > and I'll more than happily shut up about this. > > Jordan >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602110052.QAA05129>