From owner-freebsd-arch Fri Jan 19 9:43:39 2001 Delivered-To: freebsd-arch@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 23EEA37B402 for ; Fri, 19 Jan 2001 09:43:21 -0800 (PST) Received: (from daemon@localhost) by smtp02.primenet.com (8.9.3/8.9.3) id KAA08010; Fri, 19 Jan 2001 10:37:46 -0700 (MST) Received: from usr08.primenet.com(206.165.6.208) via SMTP by smtp02.primenet.com, id smtpdAAAlcaiIp; Fri Jan 19 10:37:36 2001 Received: (from tlambert@localhost) by usr08.primenet.com (8.8.5/8.8.5) id KAA10770; Fri, 19 Jan 2001 10:43:06 -0700 (MST) From: Terry Lambert Message-Id: <200101191743.KAA10770@usr08.primenet.com> Subject: Re: no newgroup/newgrp in FreeBSD? To: wes@softweyr.com (Wes Peters) Date: Fri, 19 Jan 2001 17:42:55 +0000 (GMT) Cc: will@physics.purdue.edu (Will Andrews), roam@orbitel.bg (Peter Pentchev), arch@FreeBSD.ORG In-Reply-To: <3A6728FB.76E7C687@softweyr.com> from "Wes Peters" at Jan 18, 2001 10:33:47 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Sorry for being ignorant, but what's the difference between this and the > > pw(8) group operations? > > System V only holds one GID per process. The newgrp command changes the > active GID to another group by starting a new shell with the GID specified > on the newgrp command line. You have to be a member of the group or know > the group password. Since BSD uses a list of group memberships, newgrp > is not needed. Actually, it could be useful. In SVR4, the most powerful effect is that newgrp permits you to obtain membership in a group without explicit configuration, so long as there is communication of the password to you. Specifically, it allows adjunct group membership, through knowledge of a password. The BSD method grants membership in groups explicitly. As an example, consider membership in group "wheel". To be able to "su", you must have two things: membership in group "wheel", and the "root" password. With newgrp, assuming that that you were to permit it, by assigning a group password to "wheel", instead of disallowing a "wheel" password (which would give you the explicit group membership, equivalent to what is there today), a person would need to know the "wheel" password and the "root" password instead (newgrp to "wheel", then su to "root"). An alternate formulation of this would be to have multiple group membership be ``provisional''; that is, you are a member of the explicit group associated with your passwd file entry, and a provisional member of the groups lin the group file which list you as a member. For those groups in the group file for which there is a disallowed password, membership would be granted immediately, and no newgrp-based attempt would be permitted (that's what we have today, effectively). For those groups with an explicit password, group membership would be open to all, but session transient, and require the use of a password. You could go further, and formulate it as a negative, where in order to relinquish membership, you have to supply a group password; this would be useful for exclusion groups. In any case, it's useful to think of newgrp on BSD, if only to set the "default" group to one of the groups of which a user is a member, other than their primary group (as set in the user's passwd file entry). This would have real effect in BSD, limited, of course, by the SGID bit on the directory in which a create was taking place. Again, one could consider a password: this would let you limit some operations by group membership or non-membership (as today), and add the ability to limit others based on whether or not primary membership is a particular group. Obviously, any of this could be used with password protection and group ownership and permissions on directories and files to effectively password-protect filesystem objects. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message