[
https://issues.apache.org/jira/browse/COUCHDB-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noah Slater closed COUCHDB-314.
-------------------------------
Resolution: Won't Fix
I found the following explanation:
http://www.mail-archive.com/[email protected]/msg01303.html
I am including it verbatim in this bug report in case it vanishes at any time.
Hello Richard,
thanks for the report.
* Richard Cunningham wrote on Thu, Feb 26, 2009 at 03:32:03PM CET:
> I am finding that a number of packages come with tars with world write
> on some the directories when unpacked (without a umask).
> I reported the issue to the lighttpd, who said:
>
> 'please file a bug on autotools at the gnu website. they do this on
> purpose for some unknown reason in "make dist".'
> http://redmine.lighttpd.net/issues/1921
If any, this would be an Automake bug rather than an Autoconf one.
Adding bug-automake in Cc:.
I'm not yet sure if it needs fixing, as a sensible umask avoids security
issues at unpacking time. Anyway, the current code is mandated by the
GNU Coding Standards, so if would need changing, too:
| Make sure that the directory into which the distribution unpacks (as
| well as any subdirectories) are all world-writable (octal mode 777).
| This is so that old versions of `tar' which preserve the ownership and
| permissions of the files from the tar archive will be able to extract
| all the files even if the user is unprivileged.
|
| Make sure that all the files in the distribution are world-readable.
The code in question lives in automake/lib/am/distdir.am and there
carries this comment:
## This complex find command will try to avoid changing the modes of
## links into the source tree, in case they're hard-linked. It will
## also make directories writable by everybody, because some
## brain-dead tar implementations change ownership and permissions of
## a directory before extracting the files, thus becoming unable to
## extract them.
##
## Ignore return result from chmod, because it might give an error
## if we chmod a symlink.
##
## Another nastiness: if the file is unreadable by us, we make it
## readable regardless of the number of links to it. This only
## happens in perverse cases.
[...]
This comment was added originally in:
commit 2d5c3abead3f72c457d886b92b3fbd977d273191
Author: Alexandre Oliva <ol...@...>
Date: Mon Jun 7 03:34:04 1999 +0000
* automake.in (dist_header): Avoid changing permissions of files
in the source tree, trying a complex `find/chmod' command before
falling back to plain chmod.
(handle_dist_worker): Do not create directories with mode 777, the
find above will take care of that.
* m4/init.m4: Set install_sh for find/chmod above.
Some discussion I can find from around this time in the old list
archive: <http://sourceware.org/ml/automake/1999-05/msg00036.html>.
One should note that even then, the "old tar" versions hinted at in GCS
were considered old already.
Hope that helps.
Cheers,
Ralf
> Release tarball contains directories with 777 permissions
> ---------------------------------------------------------
>
> Key: COUCHDB-314
> URL: https://issues.apache.org/jira/browse/COUCHDB-314
> Project: CouchDB
> Issue Type: Bug
> Components: Build System
> Affects Versions: 0.9
> Environment: Red Hat Enterprise Linux 5.3 fully updated
> Reporter: Nils Breunese
> Priority: Minor
>
> I unpacked the release tarball on Ubuntu 8.10 and Mac OS X 10.5.6 using the
> following tar mantra, which produces the desired result:
> $ tar zxvf apache-couchdb-0.9.0.tar.gz
> However, when running this command on Red Hat Enterprise Linux 5.3 all
> resulting directories have 777 permissions.
> Inspecting the tarball showed that the directories inside the tarball indeed
> have 777 permissions. Apparently Red Hat's tar is applying the
> -p/--preserve-permissions flag automatically, while this doesn't happen on
> Ubuntu and Mac OS X. That's why the directories look normal on Ubuntu and Mac
> OS X, as in that case the default umask is applied, which is generally set to
> 0022 and therefor yields 755 permissions for directories.
> I generally don't like having 777 directories on my system, especially when
> it serves no purpose, so could the release tarball maybe be altered to just
> have 'normal' directories with 755 permissions?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
