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