Bugs item #1882425, was opened at 2008-01-30 08:17
Message generated for change (Comment added) made by bagder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1882425&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: compile or build problem
Group: bad behaviour
>Status: Closed
Resolution: Invalid
Priority: 2
Private: No
Submitted By: Alexander Peslyak (solardiz)
Assigned to: Daniel Stenberg (bagder)
Summary: with umask 077, "make install" creates mode 700 directories

Initial Comment:
In curl 7.18.0, "make install" does specify mode 644 for files that it installs, but fails to specify mode 755 for at least some of the directories created during the install. As a result, it can't be used to perform a system-wide install when the sysadmin's umask is 077.
While honoring the umask in this way makes some sense, it is not consistent anyway, so this should be fixed in one way or the other.

----------------------------------------------------------------------

>Comment By: Daniel Stenberg (bagder)
Date: 2008-01-31 13:00

Message:
Logged In: YES
user_id=1110
Originator: NO

Well, the Makefile is generated by automake so this is rather an automake
bug than a curl one (if any). I also consider this so minor and easy to
work around that I won't bother much with it.

The Makefile.in shipped in curl 7.18.0 was generated by automake 1.9.6
which isn't the most recent version, but I did a quick local test with
automake 1.10 without seeing any difference in this regard.

If you want to, you can even make the dirs get 755 rights by doing the
install like this:

make mkdir_p="mkdir -p -m 0755 --" install

So, thanks for putting this to our attention but I'll still close this as
invalid, as the bug isn't made by us, I don't consider it to be very
important and I bet lots of people would argue that this isn't a bug in the
first place.

----------------------------------------------------------------------

Comment By: Alexander Peslyak (solardiz)
Date: 2008-01-31 04:54

Message:
Logged In: YES
user_id=1995630
Originator: YES

You're right re: GNU autotools - the uses of "mkdir -p" get introduced
between Makefile.am and Makefile.in. The patch to mkinstalldirs is fine
with me (but it is insufficient until automake is fixed, unless it already
is in a newer version). Thank you!

----------------------------------------------------------------------

Comment By: Dan Fandrich (dfandrich)
Date: 2008-01-31 03:05

Message:
Logged In: YES
user_id=236775
Originator: NO

I think what Daniel meant by "tools we just use" is the GNU autotools,
over which the curl project has no control. The exception to that is the
mkinstalldirs script. Does this patch satisfy you?

--- mkinstalldirs 10 Jan 2000 23:36:14 -0000 1.2
+++ mkinstalldirs 31 Jan 2008 02:02:49 -0000
@@ -22,9 +22,9 @@
      esac

      if test ! -d "$pathcomp"; then
- echo "mkdir $pathcomp" 1>&2
+ echo "mkdir -m0755 $pathcomp" 1>&2

- mkdir "$pathcomp" || lasterr=$?
+ mkdir -m0755 "$pathcomp" || lasterr=$?

         if test ! -d "$pathcomp"; then
          errstatus=$lasterr

I don't know how portable the -m flag is, however (it looks well supported
to me). An explicit "chmod" after the mkdir might be even better.

----------------------------------------------------------------------

Comment By: Alexander Peslyak (solardiz)
Date: 2008-01-31 02:04

Message:
Logged In: YES
user_id=1995630
Originator: YES

Thank you for the prompt response.

I agree with your guess that this is most likely a side-effect of
properties of the tools that you use, such as mkdir and install, but
whether this side-effect shows up depends on how you use the tools. For
example, "mkdir -p -m 755 dir1/dir2" is generally incorrect when used in a
package install procedure - because it does not ensure consistent
permissions for the two directories. With umask other than 022,
permissions for dir1 will be affected by the umask, whereas permissions for
dir2 will be set to 755. The correct thing to do would be either to create
the two directories separately (with explicit permissions) or to drop the
explicit permissions from the command (let both directories depend on the
umask). Other packages appear to be leaning towards the former approach
(explicit permissions for all).

Yes, this issue does exist in numerous other packages, but the percentage
of such packages appears to decrease over years.

I am using umask 077 because this is what the default umask for users and
especially for root on security-conscious distros should be, in my opinion
- and it is on ours (as well as on several others). I have tried
installing curl without changing the umask to 022 first because I knew that
many other people were likely to do the same - this was to test your
package and to report this bug.

I am saying that "make install" should either ignore the umask or fully
honor it, with my preference being the former. Right now, you have
inconsistent behavior.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2008-01-30 12:40

Message:
Logged In: YES
user_id=1110
Originator: NO

I'm almost certain this is done by tools we "just use" in this project and
thus this bug should exist for numerous packages.

So why are you installing things with umask 077 in the first place? Are
you saying the make install process should ignore your umask?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=1882425&group_id=976
Received on 2008-01-31