sudo make install

sudo make install

[Michael Heerdegen]

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.

Re: sudo make install

[Milan Stanojević]

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.
>

RE: sudo make install

[Ludwig, Mark]

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.
> >

Re: sudo make install

[Michael Heerdegen]

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.

Re: sudo make install

[Michael Heerdegen]

"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.

Re: sudo make install

[Milan Stanojević]

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.

Re: sudo make install

[Stefan Monnier]

> 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

Re: sudo make install

[Martin]

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
>
>
>

Re: sudo make install

[Michael Heerdegen]

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.

Re: sudo make install

[tomas]

-----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-----

Re: sudo make install

[Stefan Monnier]

> 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

Re: sudo make install

[Bob Proulx]

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

Re: sudo make install

[Michael Heerdegen]

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.

Re: sudo make install

[Bob Proulx]

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

Re: sudo make install

[Michael Heerdegen]

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.

Re: sudo make install

[Bob Proulx]

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

Re: sudo make install

[Michael Heerdegen]

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.

Re: sudo make install

[Bob Proulx]

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

Re: sudo make install

[Michael Heerdegen]

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.

Re: sudo make install

[Bob Proulx]

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