From owner-cvs-all Thu Oct 11 8:31:21 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 7D68A37B406; Thu, 11 Oct 2001 08:31:09 -0700 (PDT) Received: (from mi@localhost) by corbulon.video-collage.com (8.11.4/8.11.4) id f9BFV8M14208; Thu, 11 Oct 2001 11:31:08 -0400 (EDT) (envelope-from mi) From: Mikhail Teterin Message-Id: <200110111531.f9BFV8M14208@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 11:31:08 -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 > On Wed, 10 Oct 2001, Mikhail Teterin wrote: > > > > I would argue that there are several levels of visibility here > > > that could be governed by sysctl's. For example, if we take > > > 'fstat' and 'ps' I would say that a user in the wheel group > > > should have full access to both, while a user outside of wheel > > > perhaps should only have access to 'ps'. That's just an > > > example. > > > > When I hear about different access right to different information I > > think about file systems. Perhaps, this information should be made > > available through something like /proc (or something else based on > > pseudofs -- /sysctl anyone -- it already hierarchical). Then the > > admins could tune the permissions to their hearts' content. > 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? > I also played with a synthetic file system that represented TCP and > UDP ports, and ACL operations on the ports determined the rights to > connect/bind/... those ports. > 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. > 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 :) > 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 :( -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message