From: Junio C Hamano <junkio@cox.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: git@vger.kernel.org
Subject: Re: Default "tar" umask..
Date: Fri, 05 Jan 2007 14:15:26 -0800 [thread overview]
Message-ID: <7vmz4xdssh.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0701051336000.3661@woody.osdl.org> (Linus Torvalds's message of "Fri, 5 Jan 2007 13:40:38 -0800 (PST)")
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 5 Jan 2007, Junio C Hamano wrote:
>> ...
>> On the other hand, I can explain 002 fairly easily and
>> consistently.
>
> No you can't. 002 makes no sense at all in a very common old-fashioned
> setup with a "user" group.
I do not think so (see below).
> Maybe I'm old, and these days most setups seem to give people their own
> group (so I'm "torvalds:torvalds" on all the machines I have access to),
> but it used to be _very_ common to have just a "user" group that all
> normal users were part of (or have the default gid depend on something
> like which department you are in).
>
> In that situation, 002 is really effectively no different at all from 000.
I remember those days. People had 022 umask for that exact
reason, as you said, in such a setup. It was quite common. On
the other hand, modern setups often use "own" group and people
often use 002 umask.
If you extract as a normal user (i.e. without -p) then 002 is
really effectively no different at all from 000 because umask
kicks in and give the results the user would expect in either
setups, which is good. In "user" group setup, umask 022 makes
files to 0644, in "own" group setup, umask 002 makes files to
0664. All is good. If the archive is made with 022, that would
break expectation of users whose umask is 002 (a sane value in
modern "own" group setups).
The current 000 was bad for users who work as root and do not
know about implied -p (which is not their fault). When
extracting as root, the files and directories are owned by
'root' and its group.
Even in the old "user" group setups, I _thought_ the root was in
his own group or wheel in BSD, and the group was not shared with
Joe Random users, so if that is the case, group writability is
not an problem. In the modern "own" group setups, the root user
is in its own his group 'root', so group writability is not an
issue either.
> 022 really is very easy to explain: "readability (and executability) is a
> lot less dangerous than writability, and by default we only give
> writability to the user". That's why we _don't_ commonly have 066 or 077
> as the umask, and also why 002 is the default umask ONLY on systems where
> users have their own individual groups by default.
077 was a tongue-in-cheek comment.
I think we are basing our reasoning with the same shared
understanding of historical practice of "user" group. I wonder
why the differenece in conclusions.
Maybe my recollection of historical practice was faulty and the
root shared its group with Joe Random users? If so, I would
agree that 002 makes no sense at all, as you said.
next prev parent reply other threads:[~2007-01-05 22:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-30 18:45 Default "tar" umask Linus Torvalds
2006-12-30 19:27 ` Junio C Hamano
2007-01-05 20:39 ` René Scharfe
2007-01-05 21:03 ` Junio C Hamano
2007-01-05 21:40 ` Linus Torvalds
2007-01-05 22:15 ` Junio C Hamano [this message]
2007-01-07 15:20 ` Krzysztof Halasa
2007-01-07 21:28 ` Junio C Hamano
2007-01-05 22:30 ` René Scharfe
2007-01-05 22:40 ` Junio C Hamano
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=7vmz4xdssh.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=torvalds@osdl.org \
/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.
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.