From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20664 invoked from network); 18 Jul 2000 06:16:40 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 18 Jul 2000 06:16:40 -0000 Received: (qmail 28735 invoked by alias); 18 Jul 2000 06:16:26 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12293 Received: (qmail 28728 invoked from network); 18 Jul 2000 06:16:25 -0000 Date: Mon, 17 Jul 2000 23:15:57 -0700 (PDT) From: Wayne Davison X-Sender: wayne@phong.blorf.net To: zsh workers mailing list Subject: Re: PATCH: Re: adding a toplevel zsh.spec.in file In-Reply-To: <1000718052255.ZM22950@candle.brasslantern.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 18 Jul 2000, Bart Schaefer wrote: > Since RedHat made the decision to put every user in a separate > group -- something that baffles me to this day I read the reason for this, and I kind of like this strategy. Here's the gist of it: We want the default to be for (normal) newly-created files to be only writable by the owner that created them PLUS we want to make it easy for new, group-shared files to be writable by a particular group. In a more "normal" setup, the umask is 022, which requires you to manually "chmod g+w" files that need to be group writable. The RedHat solution is to set a umask of 002 (for non-super users) and to have the default group for each user be one that only the user is a member of. That way, most new files are still only writable by the owner (even with a group-writable permission) PLUS a directory with a sticky-group flag set gets files created in it that are group-writable without having to twiddle any file permissions. Kinda neat. > Obviously the maintainers of those environments believe that there's > value in the settings they place in those files. I think that RedHat/Mandrake would do well to remove all the alias, setopt, and similar setup that is going on in these /etc files and move it into the skel files that get installed for new users. This way a new user gets whatever extra setup the packager thought was desirable AND they can see the options and aliases to be able to tweak them AND an advanced user can just overwrite these files without having to add "unalias" commands and turn off non-default options in otherwise portable rc files. ..wayne..