Date: Tue, 13 Mar 2001 22:10:33 -0500 From: Sergey Babkin <babkin@bellatlantic.net> To: Robert Watson <rwatson@freebsd.org>, Mike Smith <msmith@freebsd.org>, freebsd-arch@freebsd.org, Alfred Perlstein <bright@wintelcom.net> Subject: Re: how do I get sysctl node names ? Message-ID: <3AAEE129.43C6ECBB@bellatlantic.net> References: <Pine.NEB.3.96L.1010312204734.53655A-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I've moved it to -arch instead of developers. Robert Watson wrote: > > On Mon, 12 Mar 2001, Sergey Babkin wrote: > > > I want to commit PR kern/14584. My original patch uses a sysctl variable > > to optionally enable the feature of unified UID&GID space. So I wonder > I have no problem with you adding the vfs.ufs sysctl tree. I would object > strongly to committing the UID/GID code without substantial architectural > discussion and review on at least freebsd-fs and freebsd-arch. I've discussed this idea shortly with Kirk McKusick at Usenix-2000 at the BSD BOF and he generally liked it and suggested to discuss it with you. I've sent you a personal e-mail but got no answer. Then I got distracted with other things and got back to it only now. (And yes, I wrote about it a couple of times in -hackers, with the only response from a guy who wanted to get and use my patch). > developers@FreeBSD.org is not an adequate forum for review for pretty much > anything except a developers- or commit-related policy question -- it's Well, I supposed that the sysctl namespace distribution policy is one of such policies. I'm sorry if I was wrong. > Given that I'm about go commit setfacl and getfacl, and related kernel > code to 5.0-CURRENT, and that ACLs are only marginally more confusing than > a combined uid/gid namespace, I suspect that while this is a cute > work-around to UNIX permission scariness, it's not the right long-term > solution. I'd welcome discussion on freebsd-arch/fs/et al, needless to > say, as there are some nice properties to the patch. The problem I see with ACLs is that they break all the standard Unix commands dealing with displaying or storing the permissions, such as ls, tar, cpio and others of this sort. Probably the ACLs are _the_ way to go for the high-security environments. But from my personal experience with systems administration of HP-UX and NetWare in not-so-high-security environments, the careless application of ACLs tends to cause quite a systems administration nighmare. So I personally would avoid them for as long as possible and use only when really neccessary. And that seems to be not only my experience. For example, in UnixWare the ACLs were implemented and then essentially scrapped (never ported to VxFS and left working only as remnants in SFS, a version of FFS with ACLs which does not seem to be used by anyone any more and which may not be used as a root filesystem any more). This is the reason why I think that the classic Unix permissions still have a long live ahead, so some backwards-compatible extensions to them might be quite usable. I made my patch conditionally compiled and if compiled then still disabled by default and configurable with sysctl to ensure full backwards compatibility in the default configuration. NetWare seems to have worked for quite a long time with ACLs and I think that they have found a great solution that makes the ACLs a lot cleaner: inheritance of the ACLs down the directories. But obviously the implementation of the inheritance is not so cheap. Another thing I liked in Netware is the hierarchies of groups: a group may be made a member of another group, and the control over the group permissions can be delegated to other users. This part seems to be easy enough to implement over the classic Unix model at the user level. Mike Smith wrote: > > > I want to commit PR kern/14584. My original patch uses a sysctl > > Can you elaborate on the "unified UID & GID space" concept? Basically, I It has a rather long description in the PR. In short, the idea is that all the IDs above some value get shared by both users and groups. That is, not only two users can't have the same IDs (unless they are just aliases like root and toor) and two groups can't have the same ID, but an user and a group can't have the same ID as well. This allows to use the UID field in the inodes to give permissions in the unified UID&GID space, and thus give two groups (say, "writers" and "readers") different permissions to the file wtihout resorting to trickery with subdirectories. > think you're in the right general area, but I'm not sure about "commonid" > (I'd prefer common_id, but suspect that maybe base_ugid etc. might be > more appropriate, depending on what this actually does...) common_id is fine with me. Or if there is a strong feeling that it should be something like base_ugid, that's OK too. Alfred Perlstein wrote: > > I might have missed something, but what about making it a mount > option? I think that this should be a system-wide option: the /etc/passwd ang /etc/group files are common for the whole OS, and this option describes their contents. So setting this value per filesystem makes no sense and may cause unobvious errors when different filesystems get mounted by mistake with different values of common ID. -SB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3AAEE129.43C6ECBB>