From: Bob Proulx <bob@proulx.com>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: help-gnu-emacs@gnu.org
Subject: Re: sudo make install
Date: Sun, 19 Apr 2015 18:31:53 -0600 [thread overview]
Message-ID: <20150419173947526130678@bob.proulx.com> (raw)
In-Reply-To: <87twwc8cpl.fsf@web.de>
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
next prev parent reply other threads:[~2015-04-20 0:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2015-04-20 14:57 ` Michael Heerdegen
2015-04-20 17:31 ` Bob Proulx
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150419173947526130678@bob.proulx.com \
--to=bob@proulx.com \
--cc=help-gnu-emacs@gnu.org \
--cc=michael_heerdegen@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.