From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Bob Proulx Newsgroups: gmane.emacs.help Subject: Re: sudo make install Date: Sat, 18 Apr 2015 13:32:21 -0600 Message-ID: <20150418130152206309092@bob.proulx.com> References: <87pp76wl1e.fsf@web.de> <20150415151457700363175@bob.proulx.com> <87r3rkbalh.fsf@web.de> <20150416143415154796888@bob.proulx.com> <87vbgu3iac.fsf@web.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1429385570 18653 80.91.229.3 (18 Apr 2015 19:32:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Apr 2015 19:32:50 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: Michael Heerdegen Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sat Apr 18 21:32:45 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YjYTs-0002lP-KC for geh-help-gnu-emacs@m.gmane.org; Sat, 18 Apr 2015 21:32:44 +0200 Original-Received: from localhost ([::1]:46667 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjYTr-00080X-Ub for geh-help-gnu-emacs@m.gmane.org; Sat, 18 Apr 2015 15:32:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjYTh-00080G-Nd for help-gnu-emacs@gnu.org; Sat, 18 Apr 2015 15:32:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YjYTd-0005xv-N9 for help-gnu-emacs@gnu.org; Sat, 18 Apr 2015 15:32:33 -0400 Original-Received: from joseki.proulx.com ([216.17.153.58]:32887) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjYTc-0005x0-Pi for help-gnu-emacs@gnu.org; Sat, 18 Apr 2015 15:32:29 -0400 Original-Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id A372821230; Sat, 18 Apr 2015 13:32:21 -0600 (MDT) Original-Received: by hysteria.proulx.com (Postfix, from userid 1000) id 713142DC45; Sat, 18 Apr 2015 13:32:21 -0600 (MDT) Mail-Followup-To: Michael Heerdegen , help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <87vbgu3iac.fsf@web.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 216.17.153.58 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:103839 Archived-At: Michael Heerdegen wrote: > Bob Proulx writes: > > Here we are talking about the 'staff' group. Then the user should > > have a 'umask 02' setting so that new files are created group writable > > so that the other members of the group can write them. > > Isn't there a not "missing"? I.e. user should have a 00 umask, I think. To the first question I am sorry but I don't understand "missing" in this context. I don't think I left a "not" out. To the second about a 00 umask, no. That would cause new files created writable by anyone. That isn't desirable. The 'umask 02' is perfect. Let me walk through examples. rwp@havoc:~$ mkdir /tmp/junk rwp@havoc:~$ chgrp photos /tmp/junk rwp@havoc:~$ chmod g+ws /tmp/junk I created a directory. I changed the group to the shared work group. I made sure the group was group writable, the g+w part. I made sure the group was set-group-id, the g+s part. I combined g+w and g+s into the g+ws action, group plus writable and set-id-group-id. I use and recommend the symbolic modes over the old octal modes. The g+s part means that new files are created group photos rather than the user's primary group. The user must be in group photos in order to have permissions in the directory to create files there. rwp@havoc:~$ ls -ld /tmp/junk drwxrwsr-x 2 rwp photos 4096 Apr 18 13:09 /tmp/junk rwp@havoc:~$ cd /tmp/junk rwp@havoc:/tmp/junk$ umask 077 rwp@havoc:/tmp/junk$ date > date077 rwp@havoc:/tmp/junk$ ls -l date077 -rw------- 1 rwp photos 29 Apr 18 13:10 date077 Obviously 077 isn't desirable for group use. I just put that in there because I see it often when people are scared and thinking that supermax-prison-lockdown-mode is best. rwp@havoc:/tmp/junk$ umask 022 rwp@havoc:/tmp/junk$ date > date022 rwp@havoc:/tmp/junk$ ls -l date022 -rw-r--r-- 1 rwp photos 29 Apr 18 13:10 date022 Neither is 022 good because it means that other people working in this shared photos group can't write the shared files. The classic Unix way is that all users are in the same shared 'users' group. That caused umask 022 to be used. rwp@havoc:/tmp/junk$ umask 02 rwp@havoc:/tmp/junk$ date > date02 rwp@havoc:/tmp/junk$ ls -l date02 -rw-rw-r-- 1 rwp photos 29 Apr 18 13:10 date02 Using 02 is perfect because files are created group writable. Other members of the group can work with the same files. Others not in the group can't write to those files. This works great when users are always in their own private group. My user rwp is in an rwp group. My user:group is rwp:rwp on GNU/Linux systems not rwp:users as it was on the old AT&T System V Unix. Having rwp:rwp allows me to use a 'umask 02' all of the time. Users must be in group 'photos' order to have permission to write the the date02 file. rwp@havoc:/tmp/junk$ umask 0 rwp@havoc:/tmp/junk$ date > date0 rwp@havoc:/tmp/junk$ ls -l date0 -rw-rw-rw- 1 rwp photos 29 Apr 18 13:10 date0 Using 'umask 0' means files are writable by 'other'. (In the "user", "group", "other" classifications.) That isn't good. Let's say a Wordpress PHP installation is running in the standard WP way, is cracked, and an attacking 'www-data' process tries to write to files. It could write to such a file that is writable by other. If it weren't for the 'other' write permission then that file would have been perfectly safe from the attack. If none of the files on the system are writable by other then it provides a security layer against attacking processes. (Obviously some things such as /tmp must be writable by other. But the +t bit limits attacks there.) 'rwp' is in the 'photos' group as a secondary group and therefore has permissions on files there. rwp@havoc:/tmp/junk$ id uid=1000(rwp) gid=1000(rwp) groups=1000(rwp),4(adm),27(sudo),50(staff),500(flyers),503(photos) I used 'photos' as an example in the above because I was hoping an alternate use would come at things from a different angle and be useful. People might see the utility of UPG better. But it is the same as working with 'staff' in the /usr/local directory tree. Again, if you are a solo individual working on your own laptop or whatever then umask doesn't matter. If you are in group 'staff' then you would be able to 'make install' and write the files to /usr/local without root (without sudo, without su) and the files could be written using a more restrictive 022 umask. The umask strategy above only comes into play when there are multiple users needing to share a working area. Hope that helps, Bob