Date: Thu, 11 Oct 2001 11:31:08 -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: <200110111531.f9BFV8M14208@corbulon.video-collage.com> In-Reply-To: <Pine.NEB.3.96L.1011010222607.3545A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110111531.f9BFV8M14208>