incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noah Slater (JIRA)" <j...@apache.org>
Subject [jira] Closed: (COUCHDB-314) Release tarball contains directories with 777 permissions
Date Thu, 02 Apr 2009 11:52:13 GMT

     [ 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/bug-automake@gnu.org/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.


Mime
View raw message