Date: Thu, 11 Oct 2001 11:44:16 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Mikhail Teterin <mi@corbulon.video-collage.com> 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: <Pine.NEB.3.96L.1011011113356.52802F-100000@fledge.watson.org> In-Reply-To: <200110111531.f9BFV8M14208@corbulon.video-collage.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Oct 2001, Mikhail Teterin wrote: > > BTW, speaking of additional file systems, Boris Popov has actually > > written a sysctlfs already, that you might be interested in. He also > > had a devfs variant at one point. > > I did not really have a need for it for my purposes so far. But thanks > for the pointer. Will his sysctlfs be added to -current? Last I heard, Boris did not have plans to import it, as it was an experiment. sysctl() is a faster way to get the same information, and sysctl(), unlike the file system, supports types. > > 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. I.e., if seperate entries were to exist for every possible combination of IP aliases in an interface, you begin to wonder if the better (read: simple and efficient) expression wouldn't be a rule language that could match sets of addresses using netmasks and the like. Remember that you'll need to derive new protections for new kernel objects as they appear, so as to avoid races, and current interfaces for creating many of those objects don't support providing initial protection information. > > It was an interesting experiment, but probably not the right answer in > > the general case. > > 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, ... > > If we do want to start representing the protection policies for kernel > > objects via a mechanism like this, it might be appropriate the add a > > new sysctl type for ACLs. > > Uhm, I did not get this :( 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. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services 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?Pine.NEB.3.96L.1011011113356.52802F-100000>