Date: Thu, 11 Oct 2001 12:22:25 -0400 (EDT) From: Mikhail Teterin <mi@corbulon.video-collage.com> To: Robert Watson <rwatson@FreeBSD.org> Cc: Matt Dillon <dillon@earth.backplane.com>, Dag-Erling Smorgrav <des@ofug.org>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_proc.c kern_prot.c uipc_socket.c uipc_usrreq.c src/sys/netinet raw_ip.c tcp_subr.c udp_usrreq.c Message-ID: <200110111622.f9BGMPg14672@corbulon.video-collage.com> In-Reply-To: <Pine.NEB.3.96L.1011011113356.52802F-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Unfortunately, my experience suggested that wasn't a very scalable > > > way to do the work, and the file system paradigm represented > > > multi-dimmensional policies very poorly (the namespace didn't > > > reflect wildcard-esque policies). > > > > Well, anything missing from the file system is subject to the > > traditional access control, so one only has to create nodes for > > ports/proto combos with unusual permissions. A node on such FS does > > not have to represent a single combo either -- there could be > > range/wildcard nodes just as well. This will just provide an > > interface between the kernel's database and the user-space -- > > whatever the objects in the database (ports, ranges, protocol > > wild-cards), they all need to have permissions/ACLs. > > I guess I tend to disagree. I think this model only makes sense if > there's a one-to-one mapping of synthetic FS objects and kernel > objects: if the same object is represented (sometimes in groups) by > various fs objects, the results can be confusing and inconsistent. Such mapping is what I suggest. If the kernel object is a range (like ipfw's range), the FS will store the range. If it is a single udp port or a particular sysctl node -- that's what it will be. You mentioned, wild-cards are not well expressed by an FS, well, if the kernel's object is a wildcard -- the FS will store a wildcard. > > Such "permissions database" will have to exist, whatever path is > > chosen. It seems to me, the file system is a good way to presenet > > it. The already written chmod, chown, etc. are the immediate bonuses > > :) > > A protection database of some sort has to exist, but the interface to > that database needs to reflect the requirements of the policies that > it has to express. By taking up the file system paradigm, you bring a > lot of baggage to the problem: mapping file system mode bits into > appropriate methods on the kernel object, requiring that the kernel > object have a owner and a group, limiting expression to that of > permissions, ... > The suggestion here is adding a new SYSCTL_ACL() and CTLTYPE_ACL, and > representing specific ojects in the sysctl namespace. Still suffers > from expressive limits such as those I mentioned above, but you get > less historical garbage. Well, one's garbage is another's treasure chest :) My feeling is, that the requirements the FS brings are not that horrible -- an owner of a sysctl node or tcp port has good meaning, for example. 12 (?) bits of permissions, plus flags, plus, possibly, ACLs provide quite a bit of flexibility, and the races can, probably, be addressed by setting umask properly before issuing using touch(1) :) Of course, an entirely new database can be created too, for this specific purpose, but my own (unsubstantiated) feeling is that Occam would've used his razor on it :) "In Unix everything is a file" was one of the first lessons to me... And I like the Linux' misnamed /proc for that... That said, I'm hardly qualified to actually implement any of this -- one way or the other, so my contribution is limited to this sorts of arguments. Hopefully, they reach the proverbial $0.02 treshhold... -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110111622.f9BGMPg14672>