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: Sun, 19 Apr 2015 18:31:53 -0600 Message-ID: <20150419173947526130678@bob.proulx.com> References: <87pp76wl1e.fsf@web.de> <20150415151457700363175@bob.proulx.com> <87r3rkbalh.fsf@web.de> <20150416143415154796888@bob.proulx.com> <87vbgu3iac.fsf@web.de> <20150418130152206309092@bob.proulx.com> <87twwc8cpl.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 1429490191 6145 80.91.229.3 (20 Apr 2015 00:36:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Apr 2015 00:36:31 +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 Mon Apr 20 02:36:26 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 1YjzhJ-0001av-Qi for geh-help-gnu-emacs@m.gmane.org; Mon, 20 Apr 2015 02:36:26 +0200 Original-Received: from localhost ([::1]:51349 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjzhJ-0006pc-7u for geh-help-gnu-emacs@m.gmane.org; Sun, 19 Apr 2015 20:36:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34158) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yjzh4-0006lT-7n for help-gnu-emacs@gnu.org; Sun, 19 Apr 2015 20:36:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yjzgz-0001Zz-9w for help-gnu-emacs@gnu.org; Sun, 19 Apr 2015 20:36:10 -0400 Original-Received: from joseki.proulx.com ([216.17.153.58]:42783) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yjzgy-0001Zf-Rq for help-gnu-emacs@gnu.org; Sun, 19 Apr 2015 20:36:05 -0400 Original-Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id D9D7B21838; Sun, 19 Apr 2015 18:36:02 -0600 (MDT) Original-Received: by hysteria.proulx.com (Postfix, from userid 1000) id 653D02DC4F; Sun, 19 Apr 2015 18:31:53 -0600 (MDT) Mail-Followup-To: Michael Heerdegen , help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <87twwc8cpl.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:103872 Archived-At: Michael Heerdegen wrote: > I think I got it right - but got confused by the octal notation of the > umask and the optional leading zero. I didn't find any explanation of > how the umask is interpreted for different numbers of digits. I tried > "umask 0002", and saw from the umask -S output that it was what I > wanted. Okay. Let me quickly run through an octal file permission review. Or maybe not so quickly. This turned into a very long email with a lot of details. The traditional Unix file permissions are a collection of bits. Each bit is given a specific meaning. These are represented in octal since at the time octal was the convenient form for representing a collection of bits. There were 36-bit word machines for example. Ten years later or so I think hex would be more likely used over octal. Today the standard is to use symbolic modes. Those are more portable across operating systems. (Think Cygwin for example.) The leading zero means an octal value follows. 02 is bits 1, and 0 or binary 0010. The umask 07 means binary 0111. File permissions are listed mostly in the same order as they are displayed by 'ls -l'. For example "drwxr-xr-x" decodes as: user readable user writable user searchable (the execute bit means search for directories) group readable group searchable group not writable other readable other searchable other not writable Some bits are overloaded. The setuid and setgid bits are overloaded on top of the 'x' bits. The sticky bit ('t') is overloaded on the other 'x' bit. We have been talking about /usr/local drwxrwsr-x: user readable, writable, searchable group readable, writable, searchable set-group-id is set (s is on x bit) other readable, searchable, not writable For a sticky bit example /tmp drwxrwxrwt: user readable, writable, searchable group readable, writable, searchable other readable, writable, searchable sticky bit is set (t is on x bit) The collection of bits puts the three setuid, setguid, sticky bits just ahead of the rest of the permissions. These two commands are exactly the same. chmod 02775 someshareddir chmod u=rwx,g+rwxs,o+rx someshareddir The 02775 is the bits 010 111 111 101. Or broken out individually: 0 setuid 1 setgid 0 sticky 1 read user 1 write user 1 execute (search) user 1 read group 1 write group 1 execute (search) group 1 read other 0 write other 1 execute (search) other Umask is similar. A umask of 022, typical of System V configurations where all users are in a 'users' group, is this: 0 read group 1 write group 0 execute (search) group 0 read other 1 write other 0 execute (search) other The umask is a mask. Bits that are set there mask out other bits. The zeros do nothing. The ones mask out that bit. Therefore a umask of 022 masks out group write and other write. 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 A umask of 02, typical of modern User-Private-Group systems, is this: 0 read other 1 write other 0 execute (search) other A umask of 02 only masks out the other write bit. 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 > I didn't find any explanation of how the umask is interpreted for > different numbers of digits. I tried "umask 0002", and saw from the > umask -S output that it was what I wanted. The extra zeros traditionally did nothing since after having a leading zero to indicate that the number was octal the extra zeros were simply zero and did nothing. 2 interpreted as decimal, 02 octal, 0x2 hex, or 0000002 octal are all two. Same as 0x02 or 0x00002. The leading zero indicates octal and for numbers less than seven are the same as if there wasn't a leading zero. But 08 would mean an octal 8. That is an invalid base for that number. bob@havoc:~$ umask 08 bash: umask: 08: octal number out of range Same thing for 09. Can't be octal since octal can only be 0-7. > I tried "umask 0002", and saw from the umask -S output that it was > what I wanted. Very clever! Yes. The umask -S option will print out the result using symbolic modes. rwp@havoc:~$ umask 02 rwp@havoc:~$ umask -S u=rwx,g=rwx,o=rx Sure I have used the octal modes forever. Sure I could keep using them. But I believe the symbolic modes are easier to use. Therefore I advocate for the symbolic modes over the octal modes. Also when using setgid bits the symbolic modes work intuitively while the octal modes do not with GNU coreutils chmod. rwp@havoc:/tmp$ ll -d junk drwxrwsr-x 2 rwp photos 4096 Apr 18 13:10 junk rwp@havoc:/tmp$ chmod 0775 junk rwp@havoc:/tmp$ ll -d junk drwxrwsr-x 2 rwp photos 4096 Apr 18 13:10 junk The GNU coreutils chmod made an active decision to NOT clear the setguid bit with chmod 0775. This is different from traditional systems which would have cleared that bit then. To set it with octal one would use: chmod 02775 To clear it on traditional systems (and older coreutils) would have been: chmod 0775 But that no longer clears the setgid bit. Now you would need an explicit: chmod g-s The sticky bit is another overloaded bit that means different things in different contexts. On a file it used to be a hint to the operating system that the pages once loaded into memory should stay loaded in memory. A hint that the executable is often used and would benefit users if it stayed in memory instead of being loaded from disk each time. I think it actually meant loaded in swap not memory. Under the idea that loading from swap to memory was faster than loading from file system and executing loader fixups. This usage is rather obsolescent these days. I think the Linux kernel ignores it. (Not sure and would be happy for a correction.) On a directory such as /tmp it means that only the owner of the file can remove the file. man 2 unlink EPERM or EACCES The directory containing pathname has the sticky bit (S_ISVTX) set and the process's effective UID is neither the UID of the file to be deleted nor that of the directory containing it, and the process is not privileged (Linux: does not have the CAP_FOWNER capability). > I also understood the role of the sticky bit set for "/usr/share": You mean the setguid bit not the sticky bit. And /usr/local not /usr/share. I think you derped there. :-) rwp@havoc:/tmp$ ll -d /tmp /usr/share /usr/local drwxrwxrwt 6 root root 4096 Apr 19 18:10 /tmp drwxr-xr-x 170 root root 4096 Apr 18 19:22 /usr/share drwxrwsr-x 12 root staff 4096 Apr 11 22:43 /usr/local > it causes the files I created there to be group owned by "staff" > even when it is not my primary group. Yes. Exactly! > But after all, it doesn't work as expected. When I do "make > install", even with the correct umask in effect, installed stuff in > /usr/local is not group writable. Looking at the output of "make > install", "make" seems to set the umask explicitly itself: > > --8<---------------cut here---------------start------------->8--- > [...] > Installing utilities for users to run. > umask 022 && /bin/mkdir -p "/usr/local/bin" So they set the umask explicitly to 022 there. Hmm... Not so friendly doing that there. It overrides what the user has set. If it is only files created then that should be okay anyway. Files would be seldom modified by a group. Hopefully no directories would be created or they would be created with a different than desired set of permission bits. The above tries to create /usr/local/bin but that will always have existed so will mostly be a noop unless it was previously deleted. That umask above is on a single line of the Makefile and should evaporate after that line is done. This is different from a script where the effect would have been persistent for as long as the shell lives. In a Makefile each line is a separate shell process. > for file in etags ctags emacsclient ebrowse ; do \ > /usr/bin/install -c ${file} \ > "/usr/local/bin"/` \ > echo ${file} | sed -e 's/$//' -e 's,x,x,' \ > ` || exit; \ > done > make[1]: Leaving directory '/home/micha/software/emacs/lib-src' > if test "no" = "no"; then \ > /usr/bin/install -c src/emacs "/usr/local/bin/`echo emacs-25.0.50 | sed 's,x,x,'`" || exit 1 ; \ > chmod 1755 "/usr/local/bin/`echo emacs-25.0.50 | sed 's,x,x,'`" || true; \ Here they are explicitly setting +t,u=rwx,g=rx,o=rx which sets that obsolescent sticky bit on the executable and overrides the group writable. > This prevents me from getting the result you suggested. Yes it does prevent this from working as I said. I would say that is darn unfriendly of them! Probably worth a bug report. Emacs is an old project and I suspect this is a remnant that has been around for a very long time. Things like this are probably there to avoid problems when people have a 'umask 077' in effect. If someone installs then the result would be unusuable for anyone except that user since 077 masks off all of the permissions for group and other. I assume that at one time in the past someone had a problem with such a umask setting and therefore explicitly set the bits in the installation in order to avoid that problem. This is a good example of a seesaw problem. Also known as a teeter-totter. One side goes up. The other side goes down. An example where you can't please everyone. There will always be the opposite combination that is unhappy with the behavior. However... If all of the directories exist and have the desired permissions then I expect those permissions will be preserved. That means that repeated 'make install' runs would update the files but not change the directory permissions. It is the directory permissions that are the critical permissions. The directories hold the group staff access. As long as you have directory write access then that should be sufficient. Let's discuss this further if it is not. And if it is not then that would definitely be a worthy bug report. Whew! Long message! Sorry for boring everyone but the details are important and there were a lot of details to talk about. Bob