* sudo make install @ 2015-04-14 19:46 Michael Heerdegen 2015-04-14 19:56 ` Milan Stanojević ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Michael Heerdegen @ 2015-04-14 19:46 UTC (permalink / raw) To: Emacs mailing list Hello, I noticed that since some time, "make install" does compile stuff in the emacs/ source dir , just like "make". I remember that it only used to copy files into the installation target dirs. My question: when I want to "make install", I need to use "sudo". But after that operation, the emacs/ source dir now contains files owned by root. After that, I always need to be root to "make" Emacs. I don't want that, I still want to be able to "make" as a normal user. How do others handle this? Thanks, Michael. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-14 19:46 sudo make install Michael Heerdegen @ 2015-04-14 19:56 ` Milan Stanojević 2015-04-14 20:06 ` Ludwig, Mark 2015-04-14 20:15 ` Michael Heerdegen 2015-04-15 1:05 ` Stefan Monnier 2015-04-15 21:26 ` Bob Proulx 2 siblings, 2 replies; 20+ messages in thread From: Milan Stanojević @ 2015-04-14 19:56 UTC (permalink / raw) To: Michael Heerdegen; +Cc: Emacs mailing list Just use a different prefix that doesn't require root. ./configure --prefix=some-local-dir make make install On Tue, Apr 14, 2015 at 3:46 PM, Michael Heerdegen <michael_heerdegen@web.de> wrote: > Hello, > > I noticed that since some time, "make install" does compile stuff in the > emacs/ source dir , just like "make". I remember that it only used to > copy files into the installation target dirs. > > My question: when I want to "make install", I need to use "sudo". But > after that operation, the emacs/ source dir now contains files owned by > root. After that, I always need to be root to "make" Emacs. I don't > want that, I still want to be able to "make" as a normal user. > > How do others handle this? > > > Thanks, > > Michael. > ^ permalink raw reply [flat|nested] 20+ messages in thread
* RE: sudo make install 2015-04-14 19:56 ` Milan Stanojević @ 2015-04-14 20:06 ` Ludwig, Mark 2015-04-14 20:16 ` Michael Heerdegen 2015-04-14 20:15 ` Michael Heerdegen 1 sibling, 1 reply; 20+ messages in thread From: Ludwig, Mark @ 2015-04-14 20:06 UTC (permalink / raw) To: Michael Heerdegen; +Cc: Emacs mailing list When I built Emacs 24.4 last month, I used "make" (as "myself") and then when I was happy and confident with the result, used "sudo make install"; I only ended up with a single file that's owned by root in the source directory: blessmail. I can't tell from what you wrote, but are you building everything with regular (plain) "make" before invoking "sudo make install"? Hope this helps, Mark > Milan Stanojevic wrote Tuesday, April 14, 2015 2:56 PM > > Just use a different prefix that doesn't require root. > ./configure --prefix=some-local-dir > make > make install > > > On Tue, Apr 14, 2015 at 3:46 PM, Michael Heerdegen > <michael_heerdegen@web.de> wrote: > > Hello, > > > > I noticed that since some time, "make install" does compile stuff in the > > emacs/ source dir , just like "make". I remember that it only used to > > copy files into the installation target dirs. > > > > My question: when I want to "make install", I need to use "sudo". But > > after that operation, the emacs/ source dir now contains files owned by > > root. After that, I always need to be root to "make" Emacs. I don't > > want that, I still want to be able to "make" as a normal user. > > > > How do others handle this? > > > > > > Thanks, > > > > Michael. > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-14 20:06 ` Ludwig, Mark @ 2015-04-14 20:16 ` Michael Heerdegen 0 siblings, 0 replies; 20+ messages in thread From: Michael Heerdegen @ 2015-04-14 20:16 UTC (permalink / raw) To: Ludwig, Mark; +Cc: Emacs mailing list "Ludwig, Mark" <ludwig.mark@siemens.com> writes: > I can't tell from what you wrote, but are you building everything with > regular (plain) "make" before invoking "sudo make install"? Yip - but I use master (from the git repo), I guess things changed since Emacs 24. Thanks, Michael. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-14 19:56 ` Milan Stanojević 2015-04-14 20:06 ` Ludwig, Mark @ 2015-04-14 20:15 ` Michael Heerdegen 2015-04-14 20:25 ` Milan Stanojević 1 sibling, 1 reply; 20+ messages in thread From: Michael Heerdegen @ 2015-04-14 20:15 UTC (permalink / raw) To: Milan Stanojević; +Cc: Emacs mailing list Milan Stanojević <milanst@gmail.com> writes: > Just use a different prefix that doesn't require root. > ./configure --prefix=some-local-dir > make > make install This is not good in my case. I really want to install globally (for other users), but apart from that, I need to work with the repo clone as a normal user most of the time. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-14 20:15 ` Michael Heerdegen @ 2015-04-14 20:25 ` Milan Stanojević 0 siblings, 0 replies; 20+ messages in thread From: Milan Stanojević @ 2015-04-14 20:25 UTC (permalink / raw) To: Michael Heerdegen; +Cc: Emacs mailing list On Tue, Apr 14, 2015 at 4:15 PM, Michael Heerdegen <michael_heerdegen@web.de> wrote: > Milan Stanojević <milanst@gmail.com> writes: > >> Just use a different prefix that doesn't require root. >> ./configure --prefix=some-local-dir >> make >> make install > > This is not good in my case. I really want to install globally (for > other users), but apart from that, I need to work with the repo clone as > a normal user most of the time. Ah, sorry, I misunderstood your issue. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-14 19:46 sudo make install Michael Heerdegen 2015-04-14 19:56 ` Milan Stanojević @ 2015-04-15 1:05 ` Stefan Monnier 2015-04-15 10:15 ` Martin 2015-04-15 10:25 ` Michael Heerdegen 2015-04-15 21:26 ` Bob Proulx 2 siblings, 2 replies; 20+ messages in thread From: Stefan Monnier @ 2015-04-15 1:05 UTC (permalink / raw) To: help-gnu-emacs > My question: when I want to "make install", I need to use "sudo". But > after that operation, the emacs/ source dir now contains files owned by > root. A "make install" right after "make" should not create/touch local files (exactly for the reason you show). So if you do get some root-owned files even though you did a (non-root) "make" right before the "make install", I recommend you M-x report-emacs-bug. Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-15 1:05 ` Stefan Monnier @ 2015-04-15 10:15 ` Martin 2015-04-15 10:25 ` Michael Heerdegen 1 sibling, 0 replies; 20+ messages in thread From: Martin @ 2015-04-15 10:15 UTC (permalink / raw) To: Stefan Monnier, help-gnu-emacs This might be controversial :) I've never been a fan of requiring root (uid 0) rights to install software in site-specific plases -- or install any software for that matter, but that topic is for a different mailing list. :) So this is what I've been doing for quite some time: * Use some "swadm" (Software Administration) group that has R/W access to the relevant directories (presumably /usr/local in your case) ** Maybe even extend that to "swadm-emacs" (or any other package) I only have to deal with the major distributions so /usr/local is enough for me. With the *BSD stuff you might want to choose a different site prefix, AFAIR ports/packages installs in /usr/local. Make yourself a member of that group and be done with it. In my specific case: I do like to build _and_ install with the same account. Yes that may be risky in case a build or install step goes south but practically I found that to be the easiest choice. regards, Martin On Wed, Apr 15, 2015 at 3:10 AM Stefan Monnier <monnier@iro.umontreal.ca> wrote: > > My question: when I want to "make install", I need to use "sudo". But > > after that operation, the emacs/ source dir now contains files owned by > > root. > > A "make install" right after "make" should not create/touch local files > (exactly for the reason you show). So if you do get some root-owned > files even though you did a (non-root) "make" right before the "make > install", I recommend you M-x report-emacs-bug. > > > Stefan > > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-15 1:05 ` Stefan Monnier 2015-04-15 10:15 ` Martin @ 2015-04-15 10:25 ` Michael Heerdegen 2015-04-15 10:55 ` tomas 2015-04-15 12:41 ` Stefan Monnier 1 sibling, 2 replies; 20+ messages in thread From: Michael Heerdegen @ 2015-04-15 10:25 UTC (permalink / raw) To: help-gnu-emacs Stefan Monnier <monnier@iro.umontreal.ca> writes: > A "make install" right after "make" should not create/touch local files > (exactly for the reason you show). Ah, I do have to do it right afterwards! I didn't do that. Because, I want to test a new built for a while until I install it globally. What does "right after" exactly mean? Is the last modification time of the source directory determinant? Thanks, Michael. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-15 10:25 ` Michael Heerdegen @ 2015-04-15 10:55 ` tomas 2015-04-15 12:41 ` Stefan Monnier 1 sibling, 0 replies; 20+ messages in thread From: tomas @ 2015-04-15 10:55 UTC (permalink / raw) To: Michael Heerdegen; +Cc: help-gnu-emacs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Apr 15, 2015 at 12:25:09PM +0200, Michael Heerdegen wrote: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > > > A "make install" right after "make" should not create/touch local files > > (exactly for the reason you show). > > Ah, I do have to do it right afterwards! I didn't do that. Because, I > want to test a new built for a while until I install it globally. That shouldn't be a problem IMHO. And then, unless you are testing as root, whatever you do shouldn't be able to create root-owned files in your build directory. I think you are looking at a bug of "make install". Regards - -- tomás -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlUuQ5wACgkQBcgs9XrR2kZiWwCfSpmP4jfBmEHOs5nQd5fGrbor CtQAniPIYuz+CjnkvEioqKahh/y5qkGt =vr3f -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-15 10:25 ` Michael Heerdegen 2015-04-15 10:55 ` tomas @ 2015-04-15 12:41 ` Stefan Monnier 1 sibling, 0 replies; 20+ messages in thread From: Stefan Monnier @ 2015-04-15 12:41 UTC (permalink / raw) To: help-gnu-emacs > What does "right after" exactly mean? Just that if you touch one of the files in the source tree, it might trigger some re-compilations. > Is the last modification time of the source directory determinant? I don't think so, no. Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-14 19:46 sudo make install Michael Heerdegen 2015-04-14 19:56 ` Milan Stanojević 2015-04-15 1:05 ` Stefan Monnier @ 2015-04-15 21:26 ` Bob Proulx 2015-04-16 11:01 ` Michael Heerdegen 2 siblings, 1 reply; 20+ messages in thread From: Bob Proulx @ 2015-04-15 21:26 UTC (permalink / raw) To: Michael Heerdegen; +Cc: Emacs mailing list Michael Heerdegen wrote: > I noticed that since some time, "make install" does compile stuff in the > emacs/ source dir , just like "make". I remember that it only used to > copy files into the installation target dirs. The 'make install' depends upon the 'make all' target. Everything must be up to date before installation. If everything is up to date then 'make install' only installs. If things are out of date then 'make install' first updates everything and then installs. > My question: when I want to "make install", I need to use "sudo". But > after that operation, the emacs/ source dir now contains files owned by > root. After that, I always need to be root to "make" Emacs. I don't > want that, I still want to be able to "make" as a normal user. Run 'make' and 'make check' first. Then run 'make install' only after the first is clean. > How do others handle this? I do try to keep the distribution specific advocacy to a minimum. But this was a specific question. :-) I use Debian. In Debian the /usr/local tree is group-owned by the "staff" group. I place myself in the staff group. (I also put myself in the "adm" group too. So that I can read /var/log/* files.) adduser rwp staff adduser rwp adm Then log out and log back in again so that the group assignment is made. Group assignments are only done at login time. You must log out and then log back in again to have this take effect. At that point I can write to the /usr/local tree as myself. Never use sudo there again. This *improves* security. I say again, this improves security. Since there isn't any root involved in accessing that tree it means that a buggy Makefile or malicious project no longer has one attack vector against the system. A 'make install' can't modify something in /etc for example. make make check make install No use of su or sudo in the above. Compilation is only as a non-priviledged user. Installation is only as a non-priviledged user. Installation can only modify files in /usr/local. The installation cannot modify /etc, /bin, /usr/bin, /lib, /usr/lib, or any other system location. It is trapped into the /usr/local tree exactly where it should be restricted. This will catch any project that is doing bad things in their installation process. If doing this you get a permission denied while it is trying to write files in to the main host system then you know you have found a bug. Potentially a very bad bug. Using 'sudo make install' feels very wrong to me. Download some random project from the net and give it root access to your system? That feels very wrong. In a perfect world I would container everything. The above strategy can be used on any operating system. Simply change the group ownership of the /usr/local tree. Off the top of my head: find /usr/local -exec chgrp staff {} + find /usr/local -type d -exec chmod g+ws {} + Remember that no operating system files will be packaged for the /usr/local tree (other than setting up infrastructure such as /usr/local/bin itself and other related directories there. The /usr/local tree is for the local admin to maintain and control. Bob ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-15 21:26 ` Bob Proulx @ 2015-04-16 11:01 ` Michael Heerdegen 2015-04-16 21:04 ` Bob Proulx 0 siblings, 1 reply; 20+ messages in thread From: Michael Heerdegen @ 2015-04-16 11:01 UTC (permalink / raw) To: help-gnu-emacs Hi Bob, > I use Debian. In Debian the /usr/local tree is group-owned by the > "staff" group. I place myself in the staff group. Thanks very much for your detailed answer. What you suggest seems very reasonable. I use Debian too, btw. Is the ownership of the /usr/local directory tree the only important property of the staff group, or is it used for other purposes as well? With other words: what are the consequences of adding my user to the staff group, other than that I will be able to modify the /usr/local tree? Regards, Michael. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-16 11:01 ` Michael Heerdegen @ 2015-04-16 21:04 ` Bob Proulx 2015-04-17 15:07 ` Michael Heerdegen 0 siblings, 1 reply; 20+ messages in thread From: Bob Proulx @ 2015-04-16 21:04 UTC (permalink / raw) To: Michael Heerdegen; +Cc: help-gnu-emacs Michael Heerdegen wrote: > Is the ownership of the /usr/local directory tree the only important > property of the staff group, or is it used for other purposes as well? > > With other words: what are the consequences of adding my user to the > staff group, other than that I will be able to modify the /usr/local > tree? None. There are no other consequences unless you add them on your system. First there is this entry in the Securing Debian HOWTO. https://www.debian.org/doc/manuals/securing-debian-howto/ch12.en.html#s12.1.12.3 That mentions not just /usr/local but also /home. I have seen some sites change /home to be owned by group staff and extend the group there but it is not done by default. $ ls -ld /home drwxr-xr-x 12 root root 4096 Jan 9 2014 /home The Debian Policy manual says: https://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1.2 ...a large section of details... However, because /usr/local and its contents are for exclusive use of the local administrator, a package must not rely on the presence or absence of files or directories in /usr/local for normal operation. The /usr/local directory itself and all the subdirectories created by the package should (by default) have permissions 2775 (group-writable and set-group-id) and be owned by root:staff. If you install a pristine installation of Debian and run 'find' across it you will locate two directory trees that are writable by group staff. /usr/local /var/local That is it. No other ramifications. This is all part of UPG (User-Private-Groups). In order to facilitate multiple people being able to work in a shared directory the strategy is to place those people in a shared group. 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. If you are a solo individual on your system working then the umask won't matter but I note it as part of the overall strategy. I will close by saying that the debian-user@lists.debian.org mailing list is the best place to discuss Debian specific things such as group 'staff' and 'adm' and other such things. Although I like the strategy enough that I convert the RHEL/CentOS systems I administer to that scheme too. Bob ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-16 21:04 ` Bob Proulx @ 2015-04-17 15:07 ` Michael Heerdegen 2015-04-18 19:32 ` Bob Proulx 0 siblings, 1 reply; 20+ messages in thread From: Michael Heerdegen @ 2015-04-17 15:07 UTC (permalink / raw) To: help-gnu-emacs Bob Proulx <bob@proulx.com> writes: > None. There are no other consequences unless you add them on your > system. Ok, thanks for all your input. After cleaning up the access rights of /usr/local (root did not have the correct umask when I had done "make install" in the past) everything works as I want. > 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. Regards, Michael. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-17 15:07 ` Michael Heerdegen @ 2015-04-18 19:32 ` Bob Proulx 2015-04-19 13:33 ` Michael Heerdegen 0 siblings, 1 reply; 20+ messages in thread From: Bob Proulx @ 2015-04-18 19:32 UTC (permalink / raw) To: Michael Heerdegen; +Cc: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-18 19:32 ` Bob Proulx @ 2015-04-19 13:33 ` Michael Heerdegen 2015-04-20 0:31 ` Bob Proulx 0 siblings, 1 reply; 20+ messages in thread From: Michael Heerdegen @ 2015-04-19 13:33 UTC (permalink / raw) To: help-gnu-emacs Hi Bob, > 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. thanks again for your explanations. 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. I also understood the role of the sticky bit set for "/usr/share": it causes the files I created there to be group owned by "staff" even when it is not my primary group. 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" 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; \ if test "x" = x; then \ rm -f "/usr/local/bin/`echo emacs | sed 's,x,x,'`" ; \ cd "/usr/local/bin" && ln -s `echo emacs-25.0.50 | sed 's,x,x,'` `echo emacs | sed 's,x,x,'`; \ fi; [...] --8<---------------cut here---------------end--------------->8--- This prevents me from getting the result you suggested. Thanks, Michael. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-19 13:33 ` Michael Heerdegen @ 2015-04-20 0:31 ` Bob Proulx 2015-04-20 14:57 ` Michael Heerdegen 0 siblings, 1 reply; 20+ messages in thread From: Bob Proulx @ 2015-04-20 0:31 UTC (permalink / raw) To: Michael Heerdegen; +Cc: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-20 0:31 ` Bob Proulx @ 2015-04-20 14:57 ` Michael Heerdegen 2015-04-20 17:31 ` Bob Proulx 0 siblings, 1 reply; 20+ messages in thread From: Michael Heerdegen @ 2015-04-20 14:57 UTC (permalink / raw) To: help-gnu-emacs Hello Bob, Thanks for explaining all these details. I think I'll try to rely on the symbolic representation. > So they set the umask explicitly to 022 there. Hmm... Not so > friendly doing that there. It overrides what the user has set. As you expected, that is not really a problem in my specific case. Anyway, it doesn't seem right. Would something like "umask g+r,g+x,o+r,o+x" work better in the Makefile? This would avoid to make the umask more restictive in the 002 case. > Whew! Long message! Indeed. Many thanks for your answer! Regards, Michael. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: sudo make install 2015-04-20 14:57 ` Michael Heerdegen @ 2015-04-20 17:31 ` Bob Proulx 0 siblings, 0 replies; 20+ messages in thread From: Bob Proulx @ 2015-04-20 17:31 UTC (permalink / raw) To: Michael Heerdegen; +Cc: help-gnu-emacs Michael Heerdegen wrote: > Would something like "umask g+r,g+x,o+r,o+x" work better in the > Makefile? This would avoid to make the umask more restictive in the 002 > case. Yes I would think so. Might as well combine those. I would probably want this behavior. umask u+rwx,go+rx,o-w If the user already has either 02 or 022 or 077 then it will preserve as much of that as practical. Bob ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2015-04-20 17:31 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-04-14 19:46 sudo make install Michael Heerdegen 2015-04-14 19:56 ` Milan Stanojević 2015-04-14 20:06 ` Ludwig, Mark 2015-04-14 20:16 ` Michael Heerdegen 2015-04-14 20:15 ` Michael Heerdegen 2015-04-14 20:25 ` Milan Stanojević 2015-04-15 1:05 ` Stefan Monnier 2015-04-15 10:15 ` Martin 2015-04-15 10:25 ` Michael Heerdegen 2015-04-15 10:55 ` tomas 2015-04-15 12:41 ` Stefan Monnier 2015-04-15 21:26 ` Bob Proulx 2015-04-16 11:01 ` Michael Heerdegen 2015-04-16 21:04 ` Bob Proulx 2015-04-17 15:07 ` Michael Heerdegen 2015-04-18 19:32 ` Bob Proulx 2015-04-19 13:33 ` Michael Heerdegen 2015-04-20 0:31 ` Bob Proulx 2015-04-20 14:57 ` Michael Heerdegen 2015-04-20 17:31 ` Bob Proulx
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.