From owner-cvs-all Thu Oct 11 9:22:42 2001 Delivered-To: cvs-all@freebsd.org Received: from corbulon.video-collage.com (corbulon.video-collage.com [64.35.99.179]) by hub.freebsd.org (Postfix) with ESMTP id 0361937B401; Thu, 11 Oct 2001 09:22:31 -0700 (PDT) Received: (from mi@localhost) by corbulon.video-collage.com (8.11.4/8.11.4) id f9BGMPg14672; Thu, 11 Oct 2001 12:22:25 -0400 (EDT) (envelope-from mi) From: Mikhail Teterin Message-Id: <200110111622.f9BGMPg14672@corbulon.video-collage.com> 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 In-Reply-To: To: Robert Watson Date: Thu, 11 Oct 2001 12:22:25 -0400 (EDT) Cc: Matt Dillon , Dag-Erling Smorgrav , Garrett Wollman , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL92b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > 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