* Re: R: Linux kernel source archive vulnerable
2006-09-13 1:17 ` David Wagner
@ 2006-09-13 4:33 ` Willy Tarreau
2006-09-13 5:34 ` David Wagner
2006-09-13 8:51 ` Stefan Richter
2006-09-14 23:04 ` Bill Davidsen
2 siblings, 1 reply; 23+ messages in thread
From: Willy Tarreau @ 2006-09-13 4:33 UTC (permalink / raw)
To: David Wagner; +Cc: linux-kernel
On Wed, Sep 13, 2006 at 01:17:48AM +0000, David Wagner wrote:
> Rene Scharfe wrote:
> >[details on how GNU tar works, snipped]
>
> Again, you miss my point. I already know how tar works, but that's not
> my point. Why is it that people are so unwilling to address the real
> issue here? Let's try a few facts:
>
> (a) The Linux kernel tar archive contains files with world-writeable
> permissions.
>
> (b) There is no need for those files to have world-writeable
> permissions. It doesn't serve any particular purpose. If the
> permissions in the tar archive were changed to be not world-writeable,
> no harm would be done.
>
> (c) Some users may get screwed over by virtue of the fact that those
> files are listed in the tar archive with world-writeable permissions.
> (Sure, if every user was an expert on "tar" and on security, then
> maybe no one would get screwed over. But in the real world, that's
> not the case.)
>
> (d) Consequently, the format of the Linux kernel tar archive is
> exposing some users to unnecessary riskis.
>
> (e) The Linux kernel folks could take a quick and easy step that
> would eliminate this risk. That step would involve storing the
> files in the tar archive with permissions that were more reasonable
> (not world-writeable would be a good start!). This step wouldn't
> hurt anyone. There's no downside.
>
> (f) Yet the Linux kernel folks refuse to take this step, and any
> time someone mentions that there is something the Linux kernel folks
> could do about the problem, someone tries to change the topic to
> something else (e.g., complaints about bugs in GNU tar, suggestions
> that the user should invoke tar with some other option, claims that
> this question has been addressed before, you name it).
>
> So why is it that the tar archive is structured this way? Why are
> the Linux kernel folks unnecessarily exposing their users to risk?
> What purpose, exactly, does it serve to have these files stored with
> world-writeable permissions?
>
> Folks on the Linux kernel mailing list seem to be reluctant to admit these
> facts forthrightly. The posts I've seen mostly seem to have little or
> no sympathy for users who get screwed over. The attitude seems to be:
> if you get screwed over, it's your fault and your problem. Why is that?
> If there is a simple step that Linux developers can take to eliminate
> this risk, why is there such reluctance to take it, and why is there
> such eagerness to point the finger at someone else?
>
> The way I see it, storing files in a tar archive with world-writeable
> permissions is senseless. Why do such a strange thing on purpose?
>
> It all seems thoroughly mysterious to me.
The initial reason is that Linus now uses the "git-tar-tree" command
which creates the full tar archive from the tree. It does not use tar,
it know how to produce the tar format itself. The command has to set
permissions on the files, and by default, it sets full permissions to
the files. This began in early git history. Recently, I've been using
git for another project. There, it has annoyed me to put such
permissions in tar files which mostly contained scripts. So I proposed
a patch to add the umask option to the repository config file which
solved my problem. Junio merged it into git 1.4.2 (so it's very recent).
It would be perfectly usable for linux too (in fact, I do use it on the
2.4 tree).
Maybe you should ask Linus if he considers using this ? When he initially
refused doing anything, it was when every single change would have needed
to change git. Now that git has changed, maybe Linus would consider going
back to the old behaviour ?
Regards,
Willy
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: R: Linux kernel source archive vulnerable
2006-09-13 4:33 ` Willy Tarreau
@ 2006-09-13 5:34 ` David Wagner
2006-09-13 6:17 ` Kyle Moffett
0 siblings, 1 reply; 23+ messages in thread
From: David Wagner @ 2006-09-13 5:34 UTC (permalink / raw)
To: linux-kernel
Willy Tarreau wrote:
>The initial reason is that Linus now uses the "git-tar-tree" command
>which creates the full tar archive from the tree. It does not use tar,
>it know how to produce the tar format itself. The command has to set
>permissions on the files, and by default, it sets full permissions to
>the files.
Ahh, thanks for the explanation. That's helpful.
So it sounds like git-tar-tree has a bug; its default isn't setting
meaningful permissions on the files that it puts into the tar archive.
I hope the maintainers of git-tar-tree will consider fixing this bug.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: R: Linux kernel source archive vulnerable
2006-09-13 5:34 ` David Wagner
@ 2006-09-13 6:17 ` Kyle Moffett
2006-09-13 6:26 ` David Wagner
2006-09-13 6:26 ` Jan Engelhardt
0 siblings, 2 replies; 23+ messages in thread
From: Kyle Moffett @ 2006-09-13 6:17 UTC (permalink / raw)
To: David Wagner; +Cc: linux-kernel
On Sep 13, 2006, at 01:34:01, David Wagner wrote:
> Willy Tarreau wrote:
>> The initial reason is that Linus now uses the "git-tar-tree" command
>> which creates the full tar archive from the tree. It does not use
>> tar,
>> it know how to produce the tar format itself. The command has to set
>> permissions on the files, and by default, it sets full permissions to
>> the files.
>
> Ahh, thanks for the explanation. That's helpful.
>
> So it sounds like git-tar-tree has a bug; its default isn't setting
> meaningful permissions on the files that it puts into the tar archive.
> I hope the maintainers of git-tar-tree will consider fixing this bug.
Let me reiterate: This is not a bug!
Here are a few facts:
1) When I run "touch foo", the "touch" command uses permissions
0666, which are modified by my umask before hitting the FS. (same
behavior for all UIDs)
2) When I run "gcc -c foo.c -o foo.o", the "gcc" command uses
permissions 0666, which are modified by my umask before hitting the
FS. (same behavior for all UIDs)
3) When I run "vim foo.c", the "vim" command uses permissions 0666
for new files, which are modified by my umask before hitting the FS.
(same behavior for all UIDs)
4) When I run "tar -xvf foo.tar" as a normal user, the "tar" command
uses permissions from the archive for new files, which are modified
by my umask before hitting the FS.
5) Do you see the pattern here?
Now when I run that tar command as root, for some reason they assume
that just because my UID is 0 I want to try to ignore my umask while
extracting my j_random.tar file. How does this follow from the
behavior of any other programs mentioned above?
The program "git-tar-tree" has no bug. It creates the tar archive
such that when extracted as a normal user the users' umask is applied
exactly as for every other standard program. If anything the "bug"
is in tar assuming that every archive file extracted as UID 0 is a
backup, or in the admin assuming that tar doesn't behave differently
when run as UID 0.
Cheers,
Kyle Moffett
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: R: Linux kernel source archive vulnerable
2006-09-13 6:17 ` Kyle Moffett
@ 2006-09-13 6:26 ` David Wagner
2006-09-13 6:49 ` Kyle Moffett
2006-09-13 10:45 ` Martin Mares
2006-09-13 6:26 ` Jan Engelhardt
1 sibling, 2 replies; 23+ messages in thread
From: David Wagner @ 2006-09-13 6:26 UTC (permalink / raw)
To: linux-kernel
Kyle Moffett wrote:
>On Sep 13, 2006, at 01:34:01, David Wagner wrote:
>> So it sounds like git-tar-tree has a bug; its default isn't setting
>> meaningful permissions on the files that it puts into the tar archive.
>> I hope the maintainers of git-tar-tree will consider fixing this bug.
>
>Let me reiterate: This is not a bug!
I think it is a bug. It sounds like git-tar-tree is storing the wrong
set of permissions in the tar archive. When I run "tar cf foo.tar
bar", and bar has permissions 0644, then tar inserts an entry into the
archive for "bar" with its permissions listed as 0644 (*not* 0666).
If "tar cf foo.tar bar" just ignored the permissions on bar and always
used a default of 0666 out of laziness, that would be a bug in "tar cf".
The same goes for git-tar-tree. It seems to me that git-tar-tree ought
to behave the same as "tar cf".
In any case, regardless of whether this is by design or not, it is not
courteous to your users to distribute tar files where all the files have
permissions 0666. That's not a user-friendly to do.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: R: Linux kernel source archive vulnerable
2006-09-13 6:26 ` David Wagner
@ 2006-09-13 6:49 ` Kyle Moffett
2006-09-13 6:59 ` David Wagner
2006-09-13 10:45 ` Martin Mares
1 sibling, 1 reply; 23+ messages in thread
From: Kyle Moffett @ 2006-09-13 6:49 UTC (permalink / raw)
To: David Wagner; +Cc: linux-kernel
On Sep 13, 2006, at 02:26:23, David Wagner wrote:
> Kyle Moffett wrote:
>> On Sep 13, 2006, at 01:34:01, David Wagner wrote:
>>> So it sounds like git-tar-tree has a bug; its default isn't setting
>>> meaningful permissions on the files that it puts into the tar
>>> archive.
>>> I hope the maintainers of git-tar-tree will consider fixing this
>>> bug.
>>
>> Let me reiterate: This is not a bug!
>
> I think it is a bug. It sounds like git-tar-tree is storing the
> wrong set of permissions in the tar archive.
No, git-tar-tree is storing the desired permissions (0666 and 0777)
in the tar archive. This is not a bug, those are actually the
permissions we want in the tar archive.
> When I run "tar cf foo.tar bar", and bar has permissions 0644, then
> tar inserts an entry into the archive for "bar" with its
> permissions listed as 0644 (*not* 0666).
This is irrelevant because the actual permissions copied from GIT to
the tar archive are 0666 (as desired).
> If "tar cf foo.tar bar" just ignored the permissions on bar and
> always used a default of 0666 out of laziness, that would be a bug
> in "tar cf". The same goes for git-tar-tree. It seems to me that
> git-tar-tree ought to behave the same as "tar cf".
It does; except the permissions in git are 0666 for files and 0777
for directories so that your umask takes effect when you check out
from GIT or extract a tar archive exported from GIT.
> In any case, regardless of whether this is by design or not, it is
> not courteous to your users to distribute tar files where all the
> files have permissions 0666. That's not a user-friendly to do.
No, it is user-friendly. This is like distributing programs who use
open(..., 0666) when opening globally-readable files. Programs that
use open(..., 0644) are considered uncourteous because they
intentionally ignore your umask. The only cases where that is
acceptable is user SSH private key files. Likewise we store files
with permissions 0666 in the tar archive so that the user's umask is
applied to them properly.
o Do *not* extract kernel trees as root
o Do *not* build kernel trees as root
o Do *not* package kernel trees as root
o Do install kernel packages as root
It's that simple. Please drop this discussion as it was brought up
repeatedly on this list and the fairly general consensus is that this
is not a bug in either the kernel source trees or GIT.
Cheers,
Kyle Moffett
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: R: Linux kernel source archive vulnerable
2006-09-13 6:49 ` Kyle Moffett
@ 2006-09-13 6:59 ` David Wagner
2006-09-13 8:12 ` Kyle Moffett
0 siblings, 1 reply; 23+ messages in thread
From: David Wagner @ 2006-09-13 6:59 UTC (permalink / raw)
To: linux-kernel
Kyle Moffett wrote:
>No, git-tar-tree is storing the desired permissions (0666 and 0777)
>in the tar archive. This is not a bug, those are actually the
>permissions we want in the tar archive.
Those may be the permissions *you* want, but they're not the permissions
I suspect many users would prefer. Take a look at any open-source
project that ships tar archives of their source code. Do they ship
tarballs of their source code where all the files have 0666 permissions?
Not in my experience. That should tell you something.
Telling me that this is "by design" is not a very persuasive response
when my claim is that the design is poorly chosen.
>No, it is user-friendly. This is like distributing programs who use
>open(..., 0666) when opening globally-readable files.
It's not the same. There's a reason that most other open-source
projects are careful not to distribute 0666 files in their tar archives.
>o Do *not* extract kernel trees as root
I don't see anything unreasonable about extracting tarballs from a
trusted source as root (unless, of course, the folks who put together
the tarballs are malicious or careless or can't be trusted).
I don't see any good justification for this other than that the
maintainers of git-tar-tree can't be bothered to store more reasonable
permissions in the tar archive. It smells like a workaround that is
designed to make the lives of the git-tar-tree programmers easier --
but at the cost of making users lives a little harder. That's what I
mean when I said that this decision doesn't seem very user-friendly.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: R: Linux kernel source archive vulnerable
2006-09-13 6:59 ` David Wagner
@ 2006-09-13 8:12 ` Kyle Moffett
2006-09-14 22:38 ` David Wagner
0 siblings, 1 reply; 23+ messages in thread
From: Kyle Moffett @ 2006-09-13 8:12 UTC (permalink / raw)
To: David Wagner; +Cc: linux-kernel
On Sep 13, 2006, at 02:59:31, David Wagner wrote:
> Kyle Moffett wrote:
>> No, git-tar-tree is storing the desired permissions (0666 and
>> 0777) in the tar archive. This is not a bug, those are actually
>> the permissions we want in the tar archive.
>
> Those may be the permissions *you* want, but they're not the
> permissions I suspect many users would prefer.
How do you decide what users would prefer? I seem to recall the UNIX
way to do that is umask which works perfectly with tar as a normal
user and kernel tarballs. I fail to see how you get world-writable
files from a kernel tree unless your umask is 0000 or you're using
tar in backup-mode; which is senseless on a tar file not built to
restore as a backup. For that matter, how do you determine which
user it should extract as? UID 0? Linus' UID? My UID? What
happens when I extract files on my SELinux system under the sysadm
role as UID 500? Should they get UID 0 because I have chown
permissions and the author of the tar archive was tarring as root?
Relying on GNU tar and/or the permissions embedded in a tar file you
downloaded from the internet to enforce your security policy is going
to lead to a world of pain.
Besides, even Linus said:
> I would suggest that people who compile new kernels should:
> [...]
> - compile the kernel in their own home directory, as their very own
> selves. No need to be root to compile the kernel. You need to be
> root to _install_ the kernel, but that's different.
> Take a look at any open-source project that ships tar archives of
> their source code. Do they ship tarballs of their source code
> where all the files have 0666 permissions?
Actually, if you start browsing random software tarballs you'll find
that 1 in 5 or so has world-write permissions on at _minimum_ the
root directory, more often the whole source tree.
I ran:
> for i in *.tar.gz; do tar -tvzf $i | head -n 1; done | less
on my directory of source tarballs and just going alphabetically down
the list here's a list I found with drwxrwxrwx for the root directory
of the archive:
OpenSP-1.5.1.tar.gz
bison-2.1.tar.gz
cyrus-sasl-2.1.21.tar.gz
findutils-4.2.20.tar.gz
gawk-3.1.4.tar.gz
gd-2.0.33.tar.gz
glib-1.2.10.tar.gz
gmp-4.2.1.tar.gz
guile-1.4.tar.gz
gzip-1.2.4a.tar.gz
libtool-1.5.22.tar.gz
links-0.99.tar.gz
mpfr-2.2.0.tar.gz
openMotif-2.2.3.tar.gz
If this is really a "security issue" as you claim and not an admin-
caused PEBKAC problem then a lot more software than the kernel is at
risk. At least with the kernel we can expect people to have some
idea what they're doing, with some of the software above there are
README files that say "BEGINNER TUTORIAL" and go over the basics of
configure scripts.
So is this really about security or about _you_ being too lazy to
pass the appropriate option to tar when unpacking a software tarball
as root?
Cheers,
Kyle Moffett
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: R: Linux kernel source archive vulnerable
2006-09-13 8:12 ` Kyle Moffett
@ 2006-09-14 22:38 ` David Wagner
2006-09-15 7:28 ` Stefan Richter
0 siblings, 1 reply; 23+ messages in thread
From: David Wagner @ 2006-09-14 22:38 UTC (permalink / raw)
To: linux-kernel
I get the impression that people are tired of hearing about this,
so I thought I'd collect my responses to the most recent set of posts
into a single message. I'll try to make this my last message on this
subject.
Kyle Moffett wrote:
> I fail to see how you get world-writable
> files from a kernel tree unless your umask is 0000 or you're using
> tar in backup-mode [...]
Think about this from the point of view of the user, who may well
say something like: "Huh? I don't know what you're talking about.
What do you mean, backup-mode? I didn't tell tar to use some special
mode. I used it with its default options." It seems to me that it
would be reasonable to ask that extracting the Linux tarball using the
default options should lead to some fairly sane state on the filesystem.
Kyle Moffett wrote:
> For that matter, how do you determine which
> user it should extract as? UID 0?
Yes, that is the obvious choice. It's a good default that will be
right for 99.99% of users.
Kyle Moffett wrote:
> Actually, if you start browsing random software tarballs you'll find
> that 1 in 5 or so has world-write permissions on at _minimum_ the
> root directory, more often the whole source tree.
I didn't realize that. Thanks for checking. Well, I consider that
unfortunate and poorly chosen. I guess I'm out of date.
Martin Mares wrote:
> People extracting random archives as root with preserving permissions
> (and owners) are relying on *ALL* archive creators using what they suppose
> are the right permissions, which is at least simple-minded, if not completely
> silly.
I'm not suggesting extracting random archives as root. But I don't
see a problem with extracting Linux kernel archives as root. I'm prepared
-- or I was prepared -- to trust the Linux kernel developers not to
deliberately do anything that would harm my system. After all, if the
Linux kernel developers are malicious, I'm totally screwed; the act of
running their code requires a great deal of trust, and extracting a tarball
as root seems very minor compared to that.
Martin Mares wrote:
> If you want to help such users, you should do so by helping them
> understand they do a wrong thing and not by hiding the problem in a single
> specific case.
You can do both. You can educate users, *and* provide sensible defaults
in the meantime for those users who don't already know about the risks.
Stefan Richter wrote:
> Correction: Some users who set a wrong umask when creating files by
> extraction from these archives and then attempt to build an own kernel
> from that may screw themselves over.
No, this is not correct. For non-root users who set their umask to
something silly, I agree that this is their problem, not Linux's problem.
But that's not what I'm talking about. I'm talking about the case of a
root user who extracts the tar archive with 'tar xzvf'. That's a very
natural thing to do, and what I'm saying is that unsuspecting users
are likely to get bitten by the presence of 0666 files in the Linux
kernel tarball. That seems unfortunate.
Keep in mind that there are good reasons to extract the Linux tarball
as root. There is a long-standing tradition of storing the kernel
source under /usr/src, and usually /usr/src is writeable only by root.
Moreover, I bet that many users are not intimately familiar with tar
and all its obscure options, and consequently are unaware of the need
for --no-same-permissions. Those users are likely to get bitten by
this pitfall. I still think it would be a kindness to users to not set
up this trap for them to fall into; to distribute the Linux tarball with
files that are not group- or world-writeable.
It feels to me like there is this attitude towards users that says "if you
don't know all of the esoteric tar options, you deserve what you get".
I don't believe in punishing users for their ignorance.
It's not like it would be a terrible hardship to change all the
0666 permissions to 0644. There's basically no downside to doing so.
The Linux tarballs used to have 0644-style permissions for years, and I'm
not aware of any users complaining that they wished you would change all
the 0644 permissions to 0666. Instead, it sounds like that the change to
0666 happened perhaps by accident, maybe without much discussion about
the consequences for users, and now there is inertia and resistance to
changing it back.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: R: Linux kernel source archive vulnerable
2006-09-14 22:38 ` David Wagner
@ 2006-09-15 7:28 ` Stefan Richter
0 siblings, 0 replies; 23+ messages in thread
From: Stefan Richter @ 2006-09-15 7:28 UTC (permalink / raw)
To: David Wagner; +Cc: linux-kernel
David Wagner wrote:
> Keep in mind that there are good reasons to extract the Linux tarball
> as root. There is a long-standing tradition of storing the kernel
> source under /usr/src, and usually /usr/src is writeable only by root.
This no "good reason" to extract the tarball as root.
(Anyway, the discussion about running tar as root is besides the point.)
--
Stefan Richter
-=====-=-==- =--= -====
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: R: Linux kernel source archive vulnerable
2006-09-13 6:26 ` David Wagner
2006-09-13 6:49 ` Kyle Moffett
@ 2006-09-13 10:45 ` Martin Mares
2006-09-13 11:13 ` Jan Engelhardt
1 sibling, 1 reply; 23+ messages in thread
From: Martin Mares @ 2006-09-13 10:45 UTC (permalink / raw)
To: David Wagner; +Cc: linux-kernel
Hello!
> In any case, regardless of whether this is by design or not, it is not
> courteous to your users to distribute tar files where all the files have
> permissions 0666. That's not a user-friendly to do.
I disagree.
(1) Some systems use per-user groups and create all files group-writeable
by default, i.e., they set the umask to 002. If you want to be user-friendly,
you should respect this setting, so the permissions in the tar archives you
distribute should be 666.
(2) People extracting random archives as root with preserving permissions
(and owners) are relying on *ALL* archive creators using what they suppose
are the right permissions, which is at least simple-minded, if not completely
silly. If you want to help such users, you should do so by helping them
understand they do a wrong thing and not by hiding the problem in a single
specific case.
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
First law of socio-genetics: Celibacy is not hereditary.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: R: Linux kernel source archive vulnerable
2006-09-13 10:45 ` Martin Mares
@ 2006-09-13 11:13 ` Jan Engelhardt
0 siblings, 0 replies; 23+ messages in thread
From: Jan Engelhardt @ 2006-09-13 11:13 UTC (permalink / raw)
To: Martin Mares; +Cc: David Wagner, linux-kernel
>> In any case, regardless of whether this is by design or not, it is not
>> courteous to your users to distribute tar files where all the files have
>> permissions 0666. That's not a user-friendly to do.
>
>I disagree.
>
>(1) Some systems use per-user groups and create all files group-writeable
>by default, i.e., they set the umask to 002. If you want to be user-friendly,
>you should respect this setting, so the permissions in the tar archives you
>distribute should be 666.
>
>(2) People extracting random archives as root with preserving permissions
>(and owners) are relying on *ALL* archive creators using what they suppose
>are the right permissions, which is at least simple-minded, if not completely
>silly. If you want to help such users, you should do so by helping them
>understand they do a wrong thing and not by hiding the problem in a single
>specific case.
And for those who -- for whatever reason -- extract kernelballs as root,
should go use --no-same-permission.
Jan Engelhardt
--
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: R: Linux kernel source archive vulnerable
2006-09-13 6:17 ` Kyle Moffett
2006-09-13 6:26 ` David Wagner
@ 2006-09-13 6:26 ` Jan Engelhardt
2006-09-13 19:49 ` Willy Tarreau
1 sibling, 1 reply; 23+ messages in thread
From: Jan Engelhardt @ 2006-09-13 6:26 UTC (permalink / raw)
To: Kyle Moffett; +Cc: David Wagner, linux-kernel
>>
>> Ahh, thanks for the explanation. That's helpful.
>>
>> So it sounds like git-tar-tree has a bug; its default isn't setting
>> meaningful permissions on the files that it puts into the tar archive.
>> I hope the maintainers of git-tar-tree will consider fixing this bug.
>
> Let me reiterate: This is not a bug!
>
> Here are a few facts:
>
> 4) When I run "tar -xvf foo.tar" as a normal user, the "tar" command uses
> permissions from the archive for new files, which are modified by my umask
> before hitting the FS.
>
> 5) Do you see the pattern here?
>
> Now when I run that tar command as root, for some reason they assume that just
> because my UID is 0 I want to try to ignore my umask while extracting my
> j_random.tar file. How does this follow from the behavior of any other
> programs mentioned above?
> The program "git-tar-tree" has no bug. It creates the tar archive such that
> when extracted as a normal user the users' umask is applied exactly as for
> every other standard program. If anything the "bug" is in tar assuming that
> every archive file extracted as UID 0 is a backup, or in the admin assuming
> that tar doesn't behave differently when run as UID 0.
The 'complaint' made is that while the tar archive is created, 0666 gets
written into it. However, most software projects out there always make sure
that files are 0644 before tar -cvf'ing their tree.
Jan Engelhardt
--
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: R: Linux kernel source archive vulnerable
2006-09-13 6:26 ` Jan Engelhardt
@ 2006-09-13 19:49 ` Willy Tarreau
0 siblings, 0 replies; 23+ messages in thread
From: Willy Tarreau @ 2006-09-13 19:49 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: Kyle Moffett, David Wagner, linux-kernel
On Wed, Sep 13, 2006 at 08:26:57AM +0200, Jan Engelhardt wrote:
> >>
> >> Ahh, thanks for the explanation. That's helpful.
> >>
> >> So it sounds like git-tar-tree has a bug; its default isn't setting
> >> meaningful permissions on the files that it puts into the tar archive.
> >> I hope the maintainers of git-tar-tree will consider fixing this bug.
> >
> > Let me reiterate: This is not a bug!
> >
> > Here are a few facts:
> >
> > 4) When I run "tar -xvf foo.tar" as a normal user, the "tar" command uses
> > permissions from the archive for new files, which are modified by my umask
> > before hitting the FS.
> >
> > 5) Do you see the pattern here?
> >
> > Now when I run that tar command as root, for some reason they assume that just
> > because my UID is 0 I want to try to ignore my umask while extracting my
> > j_random.tar file. How does this follow from the behavior of any other
> > programs mentioned above?
>
> > The program "git-tar-tree" has no bug. It creates the tar archive such that
> > when extracted as a normal user the users' umask is applied exactly as for
> > every other standard program. If anything the "bug" is in tar assuming that
> > every archive file extracted as UID 0 is a backup, or in the admin assuming
> > that tar doesn't behave differently when run as UID 0.
>
> The 'complaint' made is that while the tar archive is created, 0666 gets
> written into it.
Let me repeat it : git-tar-tree can use a umask to set something different.
> However, most software projects out there always make sure
> that files are 0644 before tar -cvf'ing their tree.
The real problem IMHO is that many people got used for 10 years to receive
kernels packaged by user 'linus' with perms 0644, and suddenly their
(discutable) habits are considerably upset because of what initially was
a limitation in the tool, which was argumented as a feature and might not
change anytime now.
Moral of the story : do not ever try to convince Linus he's wrong
when you disagree with him, because the argument he will give you
will quickly become desired features :-)
> Jan Engelhardt
Regards,
Willy
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: R: Linux kernel source archive vulnerable
2006-09-13 1:17 ` David Wagner
2006-09-13 4:33 ` Willy Tarreau
@ 2006-09-13 8:51 ` Stefan Richter
2006-09-14 23:04 ` Bill Davidsen
2 siblings, 0 replies; 23+ messages in thread
From: Stefan Richter @ 2006-09-13 8:51 UTC (permalink / raw)
To: David Wagner; +Cc: linux-kernel
David Wagner wrote:
> (a) The Linux kernel tar archive contains files with world-writeable
> permissions.
The group's and others' permissions in the tar archive don't matter.
They have no meaning on the local system. These archives are
distributions of sources and a few scripts --- they are not local archives.
> (b) There is no need for those files to have world-writeable
> permissions. It doesn't serve any particular purpose.
Correction: The group's and others' permissions, regardless how they are
set in the tar archive, don't serve any particular purpose. You should
consequently demand that an archive format is used which does not
transfer group's and others' permissions at all.
> (c) Some users may get screwed over by virtue of the fact that those
> files are listed in the tar archive with world-writeable permissions.
Correction: Some users who set a wrong umask when creating files by
extraction from these archives and then attempt to build an own kernel
from that may screw themselves over.
The danger here as that users who handle umask in a wrong way actually
run self-made kernels. _This_ is what you should campaign against first.
--
Stefan Richter
-=====-=-==- =--= -==-=
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: R: Linux kernel source archive vulnerable
2006-09-13 1:17 ` David Wagner
2006-09-13 4:33 ` Willy Tarreau
2006-09-13 8:51 ` Stefan Richter
@ 2006-09-14 23:04 ` Bill Davidsen
2 siblings, 0 replies; 23+ messages in thread
From: Bill Davidsen @ 2006-09-14 23:04 UTC (permalink / raw)
To: David Wagner; +Cc: Kernel Mailing List
> Chris
David Wagner wrote:
> Rene Scharfe wrote:
>> [details on how GNU tar works, snipped]
>
> Again, you miss my point. I already know how tar works, but that's not
> my point. Why is it that people are so unwilling to address the real
> issue here? Let's try a few facts:
Okay:
- you have been told told read the old posts on this topic
- you read but didn't understand
- the problem is YOU ARE DOING IT WRONG and untarring as root
The time to discuss where to put the umask was "back when," and I might
have agreed then, but now I can't see any justification to change,
because someone else would then have a problem. You want it to do
something else on your system, so do it. You shouldn't untar as root anyway.
You have not only beaten a dead horse, but dragged the carcass through
the streets.
>
> (a) The Linux kernel tar archive contains files with world-writeable
> permissions.
>
> (b) There is no need for those files to have world-writeable
> permissions. It doesn't serve any particular purpose. If the
> permissions in the tar archive were changed to be not world-writeable,
> no harm would be done.
>
> (c) Some users may get screwed over by virtue of the fact that those
> files are listed in the tar archive with world-writeable permissions.
> (Sure, if every user was an expert on "tar" and on security, then
> maybe no one would get screwed over. But in the real world, that's
> not the case.)
>
> (d) Consequently, the format of the Linux kernel tar archive is
> exposing some users to unnecessary riskis.
>
> (e) The Linux kernel folks could take a quick and easy step that
> would eliminate this risk. That step would involve storing the
> files in the tar archive with permissions that were more reasonable
> (not world-writeable would be a good start!). This step wouldn't
> hurt anyone. There's no downside.
>
> (f) Yet the Linux kernel folks refuse to take this step, and any
> time someone mentions that there is something the Linux kernel folks
> could do about the problem, someone tries to change the topic to
> something else (e.g., complaints about bugs in GNU tar, suggestions
> that the user should invoke tar with some other option, claims that
> this question has been addressed before, you name it).
>
> So why is it that the tar archive is structured this way? Why are
> the Linux kernel folks unnecessarily exposing their users to risk?
> What purpose, exactly, does it serve to have these files stored with
> world-writeable permissions?
>
> Folks on the Linux kernel mailing list seem to be reluctant to admit these
> facts forthrightly. The posts I've seen mostly seem to have little or
> no sympathy for users who get screwed over. The attitude seems to be:
> if you get screwed over, it's your fault and your problem. Why is that?
> If there is a simple step that Linux developers can take to eliminate
> this risk, why is there such reluctance to take it, and why is there
> such eagerness to point the finger at someone else?
>
> The way I see it, storing files in a tar archive with world-writeable
> permissions is senseless. Why do such a strange thing on purpose?
>
> It all seems thoroughly mysterious to me.
--
Bill Davidsen <davidsen@tmr.com>
Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.
^ permalink raw reply [flat|nested] 23+ messages in thread