From unknown Sun Jun 22 11:38:35 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#12130 <12130@debbugs.gnu.org> To: bug#12130 <12130@debbugs.gnu.org> Subject: Status: "sudo make install" applies umask to new directories Reply-To: bug#12130 <12130@debbugs.gnu.org> Date: Sun, 22 Jun 2025 18:38:35 +0000 retitle 12130 "sudo make install" applies umask to new directories reassign 12130 automake submitter 12130 Jason Eisner severity 12130 normal tag 12130 notabug thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 03 03:17:37 2012 Received: (at submit) by debbugs.gnu.org; 3 Aug 2012 07:17:37 +0000 Received: from localhost ([127.0.0.1]:58053 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SxC8d-0006a3-KY for submit@debbugs.gnu.org; Fri, 03 Aug 2012 03:17:36 -0400 Received: from eggs.gnu.org ([208.118.235.92]:51978) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sx9Hw-0002RN-Du for submit@debbugs.gnu.org; Fri, 03 Aug 2012 00:15:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sx9Aa-000534-TG for submit@debbugs.gnu.org; Fri, 03 Aug 2012 00:07:26 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:50059) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx9Aa-000530-Q8 for submit@debbugs.gnu.org; Fri, 03 Aug 2012 00:07:24 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47835) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx9AZ-0002Gt-Dd for bug-automake@gnu.org; Fri, 03 Aug 2012 00:07:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sx9AX-00051C-Vu for bug-automake@gnu.org; Fri, 03 Aug 2012 00:07:23 -0400 Received: from mail-wg0-f49.google.com ([74.125.82.49]:41426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx9AX-00050m-MN for bug-automake@gnu.org; Fri, 03 Aug 2012 00:07:21 -0400 Received: by wgbez12 with SMTP id ez12so142441wgb.30 for ; Thu, 02 Aug 2012 21:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=K4wiikOAhn3Q1zLog9wXmS5QoXyFadwUnUFvoxEN3+Y=; b=rfON2ZTNku6xaRXnLH4kcTnAvBYrTklzjRmKNwcV8qs3/hlziXSr8cMV8XBOzusuEg e8yykGHkVltmVdZTaydH3EWQy/Kbs1OOHLsUkOgQKypCaJv1BEl9yepVpzghhivwF0sL fkkd5hYK7hriUIj2ODw0fujc0rywsjsREc96AuLA5Sc234I1A7qx+octkB3hwl+r+A50 NxOWu2EuZ/NEeZeaxboJUvuFA/wTbxL/7TA44FJgL9uck/lGT8ltT28ZxXeqtmfxunOy UHcUMAtKsZVOdy1jXQXklH3YLGdl0e5S8nqNpgCyJKDu4YfrM7qbqyp4uOphfPnO8//n 72QA== Received: by 10.217.4.139 with SMTP id u11mr141520wes.190.1343966840347; Thu, 02 Aug 2012 21:07:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.245.133 with HTTP; Thu, 2 Aug 2012 21:06:50 -0700 (PDT) From: Jason Eisner Date: Fri, 3 Aug 2012 00:06:50 -0400 X-Google-Sender-Auth: BXPzr9S0WLUmBC2hS49jrjm6TWk Message-ID: Subject: "sudo make install" applies umask to new directories To: bug-automake@gnu.org Content-Type: multipart/alternative; boundary=20cf301e2f7b1bdca304c654aacb X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.1 (------) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 03 Aug 2012 03:17:33 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) --20cf301e2f7b1bdca304c654aacb Content-Type: text/plain; charset=ISO-8859-1 Hi automake folks, There are many, many generic and specific installation guides that tell you to type something like ./configure && make && sudo make install and I've been typing that for years. Unfortunately, when installing OpenFST, I just discovered that the "sudo make install" part doesn't always work. My umask is 0077, so any directories created with sudo (hence owned by root) are unreadable to ordinary users, including myself. Since following the documentation yields mysterious error messages and hard-to-fix errors[*] rather than the intended behavior, I believe that you should make ONE of the following changes: 1. Fix the documentation: Correct the instructions to users to warn them that they should reset their umask before typing sudo make install. 2. Fix the behavior: Have "make install" set the permissions on directories, just as it already does on files. For example, by using -m 755 as an option to mkdir, or otherwise overriding the umask. 3. Don't fix the behavior outright, if you think for some reason that the user's umask should sometimes be respected on new directories. But then at least have "make install" issue a warning or a y/n prompt when the current umask (or for that matter, restrictive permissions on existing directories) would result in installed resources that are not publicly readable. My own preference would be for 2. I can't understand why make install treats directory permissions inconsistently with file permissions. And I can't see why a single-user preference like a umask should be reflected in a global installation. However, if there is some reason not to do 2., then I think you should do 1. or 3. to save at least some of the headaches.[*] This problem doesn't affect all packages -- only installations that create new directories. But it has been raised repeatedly over the years. To find numerous past reports, just do websearches such as umask automake umask directories "make install" However, I think it has usually been raised with maintainers of downstream packages, who are not equipped to fix it. Nothing comes up when I search for umask on http://lists.gnu.org/archive/html/bug-automake/ . Thanks a lot for your attention! -jason [*] Following the standard installation instructions leads to a silent failure of installation. The cockeyed installation can result in mysterious error messages when you try to use it. E.g., I got messages saying that the command-line utilities couldn't find their .so files. Fixing the mistaken permissions is also tricky. Even if you figure out that your umask was at fault, you can't just change your umask and run "sudo make install" again. That's because the directories already exist and rerunning "mkdir -p" on them is a no-op. So you have to figure out which directories were created and chmod them manually. I hope this makes clear why having some kind of fix is important ... --20cf301e2f7b1bdca304c654aacb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi automake folks,

There are many, many generic and specific install= ation guides that tell you to type something like
=A0=A0=A0=A0=A0 ./conf= igure && make && sudo make install
and I've been typ= ing that for years.

Unfortunately, when installing OpenFST, I just discovered that the &quo= t;sudo make install" part doesn't always work.=A0 My umask is 0077= , so any directories created with sudo (hence owned by root) are unreadable= to ordinary users, including myself.=A0

Since following the documentation yields mysterious error messages and = hard-to-fix errors[*] rather than the intended behavior, I believe that you= should make ONE of the following changes:

1. Fix the documentation:= Correct the instructions to users to warn them that they should reset thei= r umask before typing sudo make install.=A0

2. Fix the behavior: Have "make install" set the permissions = on directories, just as it already does on files.=A0 For example, by using = -m 755 as an option to mkdir, or otherwise overriding the umask.

3. Don't fix the behavior outright, if you think for some reason that t= he user's umask should sometimes be respected on new directories.=A0 Bu= t then at least have "make install" issue a warning or a y/n prom= pt when the current umask (or for that matter, restrictive permissions on e= xisting directories) would result in installed resources that are not publi= cly readable.

My own preference would be for 2.=A0 I can't understand why make in= stall treats directory permissions inconsistently with file permissions.=A0= And I can't see why a single-user preference like a umask should be re= flected in a global installation.=A0

However, if there is some reason not to do 2., then I think you should = do 1. or 3. to save at least some of the headaches.[*]

This problem = doesn't affect all packages -- only installations that create new direc= tories.=A0 But it has been raised repeatedly over the years.=A0 To find num= erous past reports, just do websearches such as
=A0=A0=A0=A0 umask automake
=A0=A0=A0=A0 umask directories "make in= stall"
However, I think it has usually been raised with maintainers= of downstream packages, who are not equipped to fix it.=A0 Nothing comes u= p when I search for umask on http://lists.gnu.org/archive/html/bug-automake/ .=A0

Thanks a lot for your attention!

-jason

[*] Following the= standard installation instructions leads to a silent failure of installati= on.=A0 The cockeyed installation can result in mysterious error messages wh= en you try to use it.=A0 E.g., I got messages saying that the command-line = utilities couldn't=20 find their .so files.=A0=20 Fixing the mistaken permissions is also tricky.=A0 Even if you figure out= =20 that your umask=20 was at fault, you can't just change your umask and run "sudo make= =20 install" again.=A0 That's because the directories already exist an= d=20 rerunning "mkdir -p" on them is a no-op.=A0 So you have to figure= out=20 which directories were created and chmod them manually.=A0 I hope this make= s clear why having some kind of fix is important ...
--20cf301e2f7b1bdca304c654aacb-- From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 03 03:20:11 2012 Received: (at submit) by debbugs.gnu.org; 3 Aug 2012 07:20:11 +0000 Received: from localhost ([127.0.0.1]:58060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SxCB7-0006eH-MJ for submit@debbugs.gnu.org; Fri, 03 Aug 2012 03:20:11 -0400 Received: from eggs.gnu.org ([208.118.235.92]:58267) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sx9VJ-0002kB-Pt for submit@debbugs.gnu.org; Fri, 03 Aug 2012 00:28:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sx9Ny-0008Lu-VF for submit@debbugs.gnu.org; Fri, 03 Aug 2012 00:21:15 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:58988) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx9Ny-0008Lq-Sd for submit@debbugs.gnu.org; Fri, 03 Aug 2012 00:21:14 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx9Nx-0000Ia-Vz for bug-automake@gnu.org; Fri, 03 Aug 2012 00:21:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sx9Nx-0008KJ-1Y for bug-automake@gnu.org; Fri, 03 Aug 2012 00:21:13 -0400 Received: from mail-wg0-f49.google.com ([74.125.82.49]:40335) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sx9Nw-0008Jq-PI for bug-automake@gnu.org; Fri, 03 Aug 2012 00:21:12 -0400 Received: by wgbez12 with SMTP id ez12so146412wgb.30 for ; Thu, 02 Aug 2012 21:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=HxLajyKg2LpGIRG95kwwiReXLu4RDDEs/IENwIoPFMk=; b=b8IfRYzfJL3gQKs0ieh8JNKGCTxIp7mhSBVecc7xLi2NmG8+Qx015blh1kgWkhGjvN iEpAafGxXOdS1H6Z7UUPBc+/kqlsUYabtshlVjvdAB7eo1o8bGTfwf+3z3MEF3i8zSPB aeLyC+yYPe4X0p1e9qLRTaDfFtaNdmqOydhLJntn5r+U6nvlj7UaMITga6+3k2/+ahdF C8jsSyEW5JfwkRXQpQU6ddKbiD9WYq6Pn13IDqVvXM6NN9MAWwtOCogAZvfSJFnavGZh ZxJh4eUlLFClnrSERwJ7Pe3m6RuEZ19AGoiQ4ILoRqw68kgrKliByYKvBXQWnWq9Seds whsA== Received: by 10.216.9.162 with SMTP id 34mr171403wet.85.1343967671978; Thu, 02 Aug 2012 21:21:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.245.133 with HTTP; Thu, 2 Aug 2012 21:20:41 -0700 (PDT) In-Reply-To: References: From: Jason Eisner Date: Fri, 3 Aug 2012 00:20:41 -0400 X-Google-Sender-Auth: 5mFva6S9u7bjaC8tjPWB8oZibT4 Message-ID: Subject: Re: "sudo make install" applies umask to new directories To: bug-automake@gnu.org Content-Type: multipart/alternative; boundary=0016e64c2482ad8af604c654db94 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -6.1 (------) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 03 Aug 2012 03:20:08 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.1 (------) --0016e64c2482ad8af604c654db94 Content-Type: text/plain; charset=ISO-8859-1 Followup -- see this thread from 2004: http://www.digipedia.pl/usenet/thread/16496/9413/ Looks like at one point, someone fixed this problem in the way I suggested. But then a user on that thread found directory permissions of 755 too restrictive, which may have gotten the fix removed. One way to make everyone happy might be to ensure that a newly created directory has permissions of *at least* 755. (Although it's a bit peculiar to handle directories this way when files are standardly 644 ...) -jason --0016e64c2482ad8af604c654db94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Followup -- see this thread from 2004:
=A0=A0=A0 htt= p://www.digipedia.pl/usenet/thread/16496/9413/

Looks like at one= point, someone fixed this problem in the way I suggested.=A0 But then a us= er on that thread found directory permissions of 755 too restrictive, which= may have gotten the fix removed.=A0

One way to make everyone happy might be to ensure that a newly created = directory has permissions of *at least* 755.=A0 (Although it's a bit pe= culiar to handle directories this way when files are standardly 644 ...)
-jason
--0016e64c2482ad8af604c654db94-- From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 07 13:40:29 2012 Received: (at 12130) by debbugs.gnu.org; 7 Aug 2012 17:40:29 +0000 Received: from localhost ([127.0.0.1]:40137 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Synld-00025U-20 for submit@debbugs.gnu.org; Tue, 07 Aug 2012 13:40:29 -0400 Received: from mail-bk0-f44.google.com ([209.85.214.44]:37690) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Synla-00025L-Bs for 12130@debbugs.gnu.org; Tue, 07 Aug 2012 13:40:27 -0400 Received: by bkty7 with SMTP id y7so1768791bkt.3 for <12130@debbugs.gnu.org>; Tue, 07 Aug 2012 10:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=CwhdhwANSwjwUg+p0oeEqHMujWXbBB9ZrfKZ4fGfKtM=; b=HbA9TM2IbzCrTpKz5l2kxsdrk35CI7wrV+zC6girsyJdFIT2WPwiauTa6QN8UfW9nT JfDtgqKsUcDydfxmRLabnF4YKIRWOdQH3rlIKcWu0LYJWlIWogQZj8FPpOMdUq3DtO90 x/M6489CydK53ntTcxdpzpnVcqTH2vU+GbsgmCHfcyKuj00CPhMKXuTp7/8N/menpteS 81oWJkqd8heWbVn89IU9jgK4GUDUBMgxd+nzWo2jJ6ggbpCkiKNap+Iu1YaV8meh4g3E VwrOTKMb67qfMv5Sq8O77BXRuiYSREa1sJXUApkCI3PcTJKqm1PynJMjy7umNSLRY8WC ttJQ== Received: by 10.204.129.8 with SMTP id m8mr6016151bks.62.1344360744480; Tue, 07 Aug 2012 10:32:24 -0700 (PDT) Received: from [192.168.178.21] (host152-95-dynamic.2-87-r.retail.telecomitalia.it. [87.2.95.152]) by mx.google.com with ESMTPS id 25sm9187630bkx.9.2012.08.07.10.32.23 (version=SSLv3 cipher=OTHER); Tue, 07 Aug 2012 10:32:23 -0700 (PDT) Message-ID: <50215125.6090807@gmail.com> Date: Tue, 07 Aug 2012 19:32:21 +0200 From: Stefano Lattarini MIME-Version: 1.0 To: Jason Eisner Subject: Re: bug#12130: "sudo make install" applies umask to new directories References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 12130 Cc: 12130@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 08/03/2012 06:06 AM, Jason Eisner wrote: > Hi automake folks, > Hi Jason, thanks for the report. > There are many, many generic and specific installation guides that tell you > to type something like > ./configure && make && sudo make install > and I've been typing that for years. > > Unfortunately, when installing OpenFST, I just discovered that the "sudo > make install" part doesn't always work. My umask is 0077, so any > directories created with sudo (hence owned by root) are unreadable to > ordinary users, including myself. > This is indeed annoying. > Since following the documentation yields mysterious error messages and > hard-to-fix errors[*] rather than the intended behavior, I believe that you > should make ONE of the following changes: > > 1. Fix the documentation: Correct the instructions to users to warn them > that they should reset their umask before typing sudo make install. > This sounds like a good idea. Care to attempt a patch? Otherwise, I'll get to write it myself eventually (not right now). But then, reading further ... > 2. Fix the behavior: Have "make install" set the permissions on > directories, just as it already does on files. For example, by using -m > 755 as an option to mkdir, or otherwise overriding the umask. > ... I see that a patch in this direction had already been proposed: but apparently never applied (the discussion died out). Maybe we could just resurrect it ... Any opinion from the other autotoolers? > 3. Don't fix the behavior outright, if you think for some reason that the > user's umask should sometimes be respected on new directories. But then at > least have "make install" issue a warning > That would likely be lost in the very verbose "make install" output, sadly. > or a y/n prompt when the current umask > Oh no, our rules are not going to get interactive by default; not even conditionally ("if input/output is attached to a terminal, then print a prompt and ..."). There lies madness. >(or for that matter, restrictive permissions on existing directories) > would result in installed resources that are not publicly readable. > > My own preference would be for 2. > I'm undecided among 1 and 2, but leaning toward 2 by now. I'll wait a few days for some feedback by the other autotoolers before proceeding. > I can't understand why make install > treats directory permissions inconsistently with file permissions. > I'd guess hysterical raisins -- as is the case with many other warts and rough edges in Automake. > And I can't see why a single-user preference like a umask should be > reflected in a global installation. > I agree it shouldn't. > However, if there is some reason not to do 2., then I think you should do > 1. or 3. to save at least some of the headaches.[*] > > This problem doesn't affect all packages -- only installations that create > new directories. But it has been raised repeatedly over the years. To > find numerous past reports, just do websearches such as > umask automake > Thanks for this suggestion. It pointed me to the older patch I referenced above. > umask directories "make install" > However, I think it has usually been raised with maintainers of downstream > packages, who are not equipped to fix it. Nothing comes up when I search > for umask on http://lists.gnu.org/archive/html/bug-automake/ . > > Thanks a lot for your attention! > > -jason > > [*] Following the standard installation instructions leads to a silent > failure of installation. The cockeyed installation can result in > mysterious error messages when you try to use it. E.g., I got messages > saying that the command-line utilities couldn't find their .so files. > Fixing the mistaken permissions is also tricky. Even if you figure out > that your umask was at fault, you can't just change your umask and run > "sudo make install" again. That's because the directories already exist > and rerunning "mkdir -p" on them is a no-op. So you have to figure out > which directories were created and chmod them manually. I hope this makes > clear why having some kind of fix is important ... > Thanks, Stefano From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 10 05:31:33 2012 Received: (at 12130) by debbugs.gnu.org; 10 Aug 2012 09:31:33 +0000 Received: from localhost ([127.0.0.1]:45944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzlZ5-0006eL-UP for submit@debbugs.gnu.org; Fri, 10 Aug 2012 05:31:32 -0400 Received: from mail-wg0-f42.google.com ([74.125.82.42]:34944) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzlZ4-0006eC-5o for 12130@debbugs.gnu.org; Fri, 10 Aug 2012 05:31:31 -0400 Received: by wgbfm10 with SMTP id fm10so1020316wgb.3 for <12130@debbugs.gnu.org>; Fri, 10 Aug 2012 02:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Pl8xfiZvdf9ihCe8ZghFjGSMJVzRjhox6KfhNCvWnj4=; b=WCTBndhQh+sNhhwoon4LIeE+4SB+oYuElJWoOj5pjKUAXfUiAk3d71pQ51LB140SKO dwQdiVVbIOAAAbSh+b1JF0bYHnDWjcXs20jqCyJB/wJZSWdS5b5sKujyyNm7jzNb3r81 D+inK33NzZzm3xxDlBv1UHFNlZA0gE3GLB2CGYUOOQtTAZ93zse/aWd5LtNK2kvSYwD3 lwwiUbuhzAe2mSo3jRwdR9DnzYpnbSoZosDDa0JInzqN+OM3N8O8Jl4FBSdfnAbvYuyn rBMZW4X9UmsfP69u/odbKcXB9NjNlyQrnYfdU2eq3ysYdIBNL7Qu2WqQ9BQmQtP3E9sU P3nQ== Received: by 10.180.81.165 with SMTP id b5mr4443472wiy.17.1344590594919; Fri, 10 Aug 2012 02:23:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.245.133 with HTTP; Fri, 10 Aug 2012 02:22:44 -0700 (PDT) In-Reply-To: <50215125.6090807@gmail.com> References: <50215125.6090807@gmail.com> From: Jason Eisner Date: Fri, 10 Aug 2012 05:22:44 -0400 X-Google-Sender-Auth: SbCRZORr5FgcvmU7H2C9HOcFc6U Message-ID: Subject: Re: bug#12130: "sudo make install" applies umask to new directories To: Stefano Lattarini Content-Type: multipart/alternative; boundary=f46d044304eec74c1f04c6e5e41e X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 12130 Cc: 12130@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --f46d044304eec74c1f04c6e5e41e Content-Type: text/plain; charset=ISO-8859-1 Dear Stefano - Thanks very much for your sympathetic reply on the directory permissions issue. As we haven't heard back further after a few days, I'd suggest going forward with plan 2. You found that plan 2 was formerly proposed at < http://lists.gnu.org/archive/html/bug-automake/2003-05/msg00011.html>. You suspected that it wasn't applied. I believe that actually, it was applied, but then reverted because it broke someone's build. As I wrote in a followup to my original post: Followup -- see this thread from 2004: > http://www.digipedia.pl/usenet/thread/16496/9413/ > > Looks like at one point, someone fixed this problem in the way I > suggested. But then a user on that thread found directory permissions of > 755 too restrictive, which may have gotten the fix removed. > > One way to make everyone happy might be to ensure that a newly created > directory has permissions of *at least* 755. (Although it's a bit peculiar > to handle directories this way when files are standardly 644 ...) In other words, perhaps the mode of the newly created directory (the XXX in mkdir -p -m XXX) needs to be be the bitwise "OR" of 755 and the current umask. By erring on the side of permissiveness, this hack allows "make install" to succeed from any user account (as I hoped), while still preserving backward compatibility (for the guy who complained above in 2004 that he wanted it to work differently from HIS user account). This is one of those backward compatibility hacks that results in inelegant behavior. I wish the 2004 guy had not relied on getting umask permissions for directories (he couldn't have relied on umask permissions for files, since those are standardly 644). But it might be worth it if anyone is still relying on this behavior. If so, maybe the generated makefile should have a comment explaining that the "OR" with umask is only for backward compatibility with previous versions of automake. cheers, jason --f46d044304eec74c1f04c6e5e41e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Stefano - Thanks very much for your sympathetic reply on the directory= permissions issue. As we haven't heard back further after a few days, = I'd suggest going forward with plan 2.

You found that plan 2 was= formerly proposed at <http://lists.gnu.org/arch= ive/html/bug-automake/2003-05/msg00011.html>.=A0 You suspected that = it wasn't applied.=A0 I believe that actually, it was applied, but then= reverted because it broke someone's build.=A0 As I wrote in a followup= to my original post:

Followup -- see this = thread from 2004:
=A0=A0=A0 http://www.digipedia.pl/usenet/thread/16496/9413/

= Looks like at one point, someone fixed this problem in the way I suggested.=A0= =20 But then a user on that thread found directory permissions of 755 too=20 restrictive, which may have gotten the fix removed.=A0

One way to m= ake everyone happy might be to ensure that a newly=20 created directory has permissions of *at least* 755.=A0 (Although it's = a=20 bit peculiar to handle directories this way when files are standardly=20 644 ...)

In other words, perhaps the mode of the newly= created directory (the XXX in mkdir -p -m XXX) needs to be be the bitwise = "OR" of 755 and the current umask. =A0

By erring on the s= ide of permissiveness, this hack allows "make install" to succeed= from any user account (as I hoped), while still preserving backward compat= ibility (for the guy who complained above in 2004 that he wanted it to work= differently from HIS user account).=A0

This is one of those backward compatibility hacks that results in inele= gant behavior.=A0 I wish the 2004 guy had not relied on getting umask permi= ssions for directories (he couldn't have relied on umask permissions fo= r files, since those are standardly 644).=A0 But it might be worth it if an= yone is still relying on this behavior.=A0 If so, maybe the generated makef= ile should have a comment explaining that the "OR" with umask is = only for backward compatibility with previous versions of automake.

cheers, jason
--f46d044304eec74c1f04c6e5e41e-- From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 10 05:56:14 2012 Received: (at 12130) by debbugs.gnu.org; 10 Aug 2012 09:56:14 +0000 Received: from localhost ([127.0.0.1]:46055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Szlwz-0007Ef-RE for submit@debbugs.gnu.org; Fri, 10 Aug 2012 05:56:14 -0400 Received: from mail-bk0-f44.google.com ([209.85.214.44]:40857) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Szlwx-0007EX-BK for 12130@debbugs.gnu.org; Fri, 10 Aug 2012 05:56:12 -0400 Received: by bkty7 with SMTP id y7so553245bkt.3 for <12130@debbugs.gnu.org>; Fri, 10 Aug 2012 02:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=86pVNXAWviekaT5CPq5jD6U/s3QGJn7QsYzswftUnCc=; b=swK0H+za5CJyvB1HkuzCWhZJfN6rCEMMkZAUPPdUNKrta6MSd1S0uQyR5gzvjOMQmy Cf6hZvePqp0Qc+ic1X4ixOjb+H/0JoQMR4OjlVN5q4iq/NRoYyS7+W6nEFi0BdYuDHXw 5dxbky+IEcNZgUdVaqLP59uQaDhKTsCY1qOv+FXQ3K10jSKs9yD85ScRkoaMA7lEfPf3 5GvmjZ5BFq8SZJQNSLob1Lzvqrk+GkP4gWtmW0P6nZaF5lxnO1wnepIQL8n5KFbkzIaT txy8aOvnxAqsK/PNUEpdeI9Oz05B753k2UlMkbngY85dR+LhstZo9/+VaewkPQP7maQy 0FOw== Received: by 10.205.123.8 with SMTP id gi8mr865130bkc.92.1344592075837; Fri, 10 Aug 2012 02:47:55 -0700 (PDT) Received: from [192.168.178.21] (host152-95-dynamic.2-87-r.retail.telecomitalia.it. [87.2.95.152]) by mx.google.com with ESMTPS id c18sm1795958bkv.8.2012.08.10.02.47.54 (version=SSLv3 cipher=OTHER); Fri, 10 Aug 2012 02:47:55 -0700 (PDT) Message-ID: <5024D8C8.9090904@gmail.com> Date: Fri, 10 Aug 2012 11:47:52 +0200 From: Stefano Lattarini MIME-Version: 1.0 To: Jason Eisner Subject: Re: bug#12130: "sudo make install" applies umask to new directories References: <50215125.6090807@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 12130 Cc: 12130@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 08/10/2012 11:22 AM, Jason Eisner wrote: > Dear Stefano - Thanks very much for your sympathetic reply on the directory > permissions issue. As we haven't heard back further after a few days, I'd > suggest going forward with plan 2. > > You found that plan 2 was formerly proposed at > . You > suspected that it wasn't applied. I believe that actually, it was applied, > but then reverted because it broke someone's build. > > As I wrote in a followup to my original post: > > Followup -- see this thread from 2004: >> http://www.digipedia.pl/usenet/thread/16496/9413/ >> You're right; here's the same discussion archived on a more "official" site: Thanks for correcting me and saving me from a potential mistake! >> Looks like at one point, someone fixed this problem in the way I >> suggested. But then a user on that thread found directory permissions of >> 755 too restrictive, which may have gotten the fix removed. >> >> One way to make everyone happy might be to ensure that a newly created >> directory has permissions of *at least* 755. >> (Although it's a bit peculiar to handle directories this way when >> files are standardly 644 ...) > Exactly. I believe we should either re-install the patch forcing the 755 permission on the intermediate directories, or enhance the install rules to respect the user umask for the installation of regular files as well. This is something to consider carefully though, and only to be changed (if we decide to change it) in the next major automake version. For now, we should content ourselves with the documentation fix you proposed. > In other words, perhaps the mode of the newly created directory (the XXX in > mkdir -p -m XXX) needs to be be the bitwise "OR" of 755 and the current > umask. > I disagree. If we want to honour the user umask, we should do so fully; half-hearted solutions (in one direction or another) will end up creating confusion, and more problems than they solve. > By erring on the side of permissiveness, this hack allows "make install" to > succeed from any user account (as I hoped), while still preserving backward > compatibility (for the guy who complained above in 2004 that he wanted it > to work differently from HIS user account). > > This is one of those backward compatibility hacks that results in inelegant > behavior. I wish the 2004 guy had not relied on getting umask permissions > for directories (he couldn't have relied on umask permissions for files, > since those are standardly 644). But it might be worth it if anyone is > still relying on this behavior. > > If so, maybe the generated makefile should > have a comment explaining that the "OR" with umask is only for backward > compatibility with previous versions of automake. > > cheers, jason > Thanks, Stefano From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 10 08:52:15 2012 Received: (at 12130) by debbugs.gnu.org; 10 Aug 2012 12:52:15 +0000 Received: from localhost ([127.0.0.1]:46346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzohK-0003ka-8T for submit@debbugs.gnu.org; Fri, 10 Aug 2012 08:52:14 -0400 Received: from mail-we0-f172.google.com ([74.125.82.172]:53552) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1SzohH-0003kS-Mj for 12130@debbugs.gnu.org; Fri, 10 Aug 2012 08:52:12 -0400 Received: by weyu54 with SMTP id u54so1005811wey.3 for <12130@debbugs.gnu.org>; Fri, 10 Aug 2012 05:43:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=/6xDO2flWQmR+5pkuv9Gmlfp7uCpZAdhtCO/ScJYR+8=; b=sr2rwOxIdBLYMVaAviM2+DdsZvFbn7pfoacS0e9Qif5Li2gpcO3z1YmePLtvAqVskR B7f3QGeQdNLq/VAcQrUQMRQgDFqmThJC4ipdV4yJRFReEbkRMveMRpGIEwqCMoQ/O7Zv xFLMD8NKGZ9VB9/VccJMDvTyc+9AHeHNa5bpGQjALjzCYsM8TW+B05YUEgyd89rFmdAO gUeerx2FgGuYd1Rh+u5X+AhoHHDx7oIYGsWAZOGLNBFNcoeAifvB1i85RnLnQfKMdfyw muSTN7P9OTdGNTU31IFuQ2kncLFZCktahseQ6XH1Xt6ITOpOWlUAvNrqAqg8ugmAj8Es pZ2Q== Received: by 10.180.81.133 with SMTP id a5mr5819960wiy.17.1344602635618; Fri, 10 Aug 2012 05:43:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.245.133 with HTTP; Fri, 10 Aug 2012 05:43:25 -0700 (PDT) In-Reply-To: <5024D8C8.9090904@gmail.com> References: <50215125.6090807@gmail.com> <5024D8C8.9090904@gmail.com> From: Jason Eisner Date: Fri, 10 Aug 2012 08:43:25 -0400 X-Google-Sender-Auth: ZBqaE6jogFssM5mI2MBGJSy_yZE Message-ID: Subject: Re: bug#12130: "sudo make install" applies umask to new directories To: Stefano Lattarini Content-Type: multipart/alternative; boundary=f46d044401de75ca2104c6e8b2fc X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 12130 Cc: 12130@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --f46d044401de75ca2104c6e8b2fc Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 10, 2012 at 5:47 AM, Stefano Lattarini < stefano.lattarini@gmail.com> wrote: > This is something to consider carefully though, and only to be changed (if > we decide to change it) in the next major automake version. For now, we > should content ourselves with the documentation fix you proposed. > When is the next major version? I'm guessing that a mere docfix won't help existing packages because they are unlikely to replace their documentation when they rerun automake (?). > In other words, perhaps the mode of the newly created directory (the XXX > in > > mkdir -p -m XXX) needs to be be the bitwise "OR" of 755 and the current > > umask. > > > I disagree. If we want to honour the user umask, we should do so fully; > half-hearted solutions (in one direction or another) will end up creating > confusion, and more problems than they solve. > Perhaps. But if you wish to preserve backward compatibility, that appears to require some degree of inconsistency (as is typical). In particular, it will require treating umask differently on files and directories, because that is what has been done in the past. Making the behavior consistent seems likely to break backward compatibility. If we start honoring umask on everything, that will break a large number of existing installation habits or scripts that relied on install to use 644 on files. If we start ignoring umask on everything, that will break a smaller number of existing installation habits or scripts that relied on a more permissive umask on directories (i.e., the guy who complained in 2004). The only ways I can see to make it consistent between files and directories are to use the "OR" solution for both, or to ignore umask by default but have a command-line flag on "sudo make install" that says "please respect my umask" (for the few users who want to rely on it to get nonstandard installation permissions at their site). --f46d044401de75ca2104c6e8b2fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 10, 2012 at 5:47 AM, Stefano Lattari= ni <stefano.lattarini@gmail.com> wrote:
This is something to consider carefully though, and only to be changed (if = we decide to change it) in the next major automake version. =A0For now, we should content ourselves with the documentation fix you proposed.

When is the next major version?=A0 I'm guessing that a = mere docfix won't help existing packages because they are unlikely to r= eplace their documentation when they rerun automake (?).

> In other words, perhaps the mode of the newly create= d directory (the XXX in
> mkdir -p -m XXX) needs to be be the bitwise "OR" of 755 and = the current
> umask.
>
I disagree. =A0If we want to honour the user umask, we should do so f= ully;
half-hearted solutions (in one direction or another) will end up creating confusion, and more problems than they solve.

Perh= aps.=A0 But if you wish to preserve backward compatibility, that appears to= require some degree of inconsistency (as is typical).=A0 In particular, it= will require treating umask differently on files and directories, because = that is what has been done in the past.=A0 Making the behavior consistent s= eems likely to break backward compatibility.=A0 If we start honoring umask = on everything, that will break a large number of existing installation habi= ts or scripts that relied on install to use 644 on files.=A0 If we start ig= noring umask on everything, that will break a smaller number of existing in= stallation habits or scripts that relied on a more permissive umask on dire= ctories (i.e., the guy who complained in 2004).=A0=A0

The only ways I can see to make it consistent between files and directo= ries are to use the "OR" solution for both, or to ignore umask by= default but have a command-line flag on "sudo make install" that= says "please respect my umask" (for the few users who want to re= ly on it to get nonstandard installation permissions at their site).
--f46d044401de75ca2104c6e8b2fc-- From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 21 00:47:30 2012 Received: (at 12130) by debbugs.gnu.org; 21 Aug 2012 04:47:30 +0000 Received: from localhost ([127.0.0.1]:40864 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3gNF-0005nQ-DQ for submit@debbugs.gnu.org; Tue, 21 Aug 2012 00:47:29 -0400 Received: from mail-ee0-f44.google.com ([74.125.83.44]:64453) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3gND-0005nJ-Ie for 12130@debbugs.gnu.org; Tue, 21 Aug 2012 00:47:28 -0400 Received: by eekb45 with SMTP id b45so1675834eek.3 for <12130@debbugs.gnu.org>; Mon, 20 Aug 2012 21:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=aSSBJ4flJ2kLdtIcC2Er2y6x+g4X/5RkqV8gTAdNYtI=; b=hjJzhR9C9iAJFCpSY38io9v7N8B3t2Mhxgr33qIhpr6mDg7TC2Fn6gzI4zsVmhPWuL DBrX7vfEfLTaTkQta0UidBX9La4pehK0I045i5rbFVyfnD98x3T4zkufBOGBa2gyc0zD aDUVWRYpOLBbN/12SV62p03fDSVstDJoBI1sSJWm5AkpuOSQtoV+COViRjxOKFdC0c0i 8d4vOTWGpxQaZehqGAsWmzcGZ+0rNejLqwHN4WFZi78+kh+TdcD1qgfdfWCGbUDvlzSC XQ1UZOMxCF4IrJvqVxQWiRvwMS2+x0iCkWtbbosiXDceRtD+RB9QIGWXcSPxMd4cJ76Q pmlA== Received: by 10.14.218.134 with SMTP id k6mr11763055eep.14.1345524429790; Mon, 20 Aug 2012 21:47:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.96.10 with HTTP; Mon, 20 Aug 2012 21:46:39 -0700 (PDT) In-Reply-To: References: <50215125.6090807@gmail.com> <5024D8C8.9090904@gmail.com> From: Jason Eisner Date: Tue, 21 Aug 2012 00:46:39 -0400 X-Google-Sender-Auth: aqf8U7Yjs5mb5l1KHznC4_7Th_A Message-ID: Subject: Fwd: bug#12130: "sudo make install" applies umask to new directories To: Stefano Lattarini Content-Type: multipart/alternative; boundary=047d7b6224c2ac9db804c7bf51dd X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 12130 Cc: 12130@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --047d7b6224c2ac9db804c7bf51dd Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 10, 2012 at 8:43 AM, Jason Eisner wrote: > The only ways I can see to make it consistent between files and > directories are to use the "OR" solution for both, or to ignore umask by > default but have a command-line flag on "sudo make install" that says > "please respect my umask" (for the few users who want to rely on it to get > nonstandard installation permissions at their site). > Better idea: Have default 644 for files and 755 for directories, but let the user override this by explicitly specifying any of * the desired file permissions * the desired directory permissions for newly created directories * the desired group owner for newly created files and directories via command-line options on "make install". The 644/755 default is consistent and will work right for almost everyone. But the command-line flag is useful for users who want to install with different conventions. I like this better than a 1-bit flag that says "please respect my umask." -jason --047d7b6224c2ac9db804c7bf51dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 10, 2012 at 8:43 AM, Jason Eisner <j= ason@cs.jhu.edu> wrote:
The only ways I can see to make it consiste= nt between files and directories are to use the "OR" solution for= both, or to ignore umask by default but have a command-line flag on "= sudo make install" that says "please respect my umask" (for = the few users who want to rely on it to get nonstandard installation permis= sions at their site).

Better idea:

Have default 644 for = files and 755 for=20 directories, but let the user override this by explicitly specifying any of=
* the desired file permissions
* the desired directory permissions f= or newly created directories
* the desired group owner for newly created= files and directories
via command-line options on "make install".

The 644/755 d= efault is consistent and will work right for almost everyone.=A0 But the co= mmand-line flag is useful for users who want to install with different conv= entions.=A0 I like this better than a 1-bit flag that says "please res= pect my umask."

-jason

--047d7b6224c2ac9db804c7bf51dd-- From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 21 00:59:08 2012 Received: (at 12130) by debbugs.gnu.org; 21 Aug 2012 04:59:08 +0000 Received: from localhost ([127.0.0.1]:40873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3gYW-00062p-6Y for submit@debbugs.gnu.org; Tue, 21 Aug 2012 00:59:08 -0400 Received: from mail-pb0-f44.google.com ([209.85.160.44]:58437) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T3gYU-00062h-7v for 12130@debbugs.gnu.org; Tue, 21 Aug 2012 00:59:06 -0400 Received: by pbbrr4 with SMTP id rr4so9703412pbb.3 for <12130@debbugs.gnu.org>; Mon, 20 Aug 2012 21:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+P1uzscgqekWC+LdwDP59200qNpBGOZpFrfTkxl2ZQg=; b=RjNXUUJctixrVvlGzAjdO0XdxLRNCI7/7r4EbP7le9QO1kWxYBtKzS1UuUF8DiqegP 8zSo4HYfEvi9dMR147bfttvBfEP6+zgeHVWodyIQr3cK92KfCSqgB6uTaBmA6n01xoIN c4ibj5CFrKoQYF8bOCHbJ8FnoxexlmjCyuALtyDQTpWc2BDi1rt6JaI4RyFLWadaeIXi 2MP1AwojCHji/QMAgXoiFQESj1ALidEfnRSKz793S3aUCgLa7BrhkboVCXTGm5i4ryiI CxzC8pSNYfZf7IK8XY38J7WNGNHV7b0S7hT954U1m1DFDMOse0nQmaFA0yB/c6Q9xZVI 6OWQ== Received: by 10.68.201.104 with SMTP id jz8mr40352861pbc.160.1345525128099; Mon, 20 Aug 2012 21:58:48 -0700 (PDT) Received: from [152.98.48.237] (gateway.qimr.edu.au. [152.98.8.1]) by mx.google.com with ESMTPS id hx9sm617057pbc.68.2012.08.20.21.58.45 (version=SSLv3 cipher=OTHER); Mon, 20 Aug 2012 21:58:47 -0700 (PDT) Message-ID: <503314DB.8060902@gmail.com> Date: Tue, 21 Aug 2012 14:55:55 +1000 From: Peter Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.6esrpre) Gecko/20120714 Thunderbird/10.0.6 MIME-Version: 1.0 To: Jason Eisner Subject: Re: bug#12130: Fwd: bug#12130: "sudo make install" applies umask to new directories References: <50215125.6090807@gmail.com> <5024D8C8.9090904@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 12130 Cc: 12130@debbugs.gnu.org, Stefano Lattarini X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On 08/21/2012 02:46 PM, Jason Eisner wrote: > Better idea: > > Have default 644 for files and 755 for directories, but let the user > override this by explicitly specifying any of > * the desired file permissions > * the desired directory permissions for newly created directories > * the desired group owner for newly created files and directories > via command-line options on "make install". > > You can already do this. You can, e.g., install packages with make install MKDIR_P="mkdir -p -m 700" Cheers, Peter From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 22 02:21:17 2012 Received: (at 12130) by debbugs.gnu.org; 22 Aug 2012 06:21:17 +0000 Received: from localhost ([127.0.0.1]:42504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T44JU-0004e5-BN for submit@debbugs.gnu.org; Wed, 22 Aug 2012 02:21:16 -0400 Received: from mail-ey0-f172.google.com ([209.85.215.172]:38367) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1T44JI-0004dV-Ml for 12130@debbugs.gnu.org; Wed, 22 Aug 2012 02:21:09 -0400 Received: by eaai11 with SMTP id i11so152112eaa.3 for <12130@debbugs.gnu.org>; Tue, 21 Aug 2012 23:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=GhFWW8vgNaa7cBRDEmrFrHynx0kaw5PcYIxhACkG8xU=; b=BukzZWpF2dp+8HCjl/J7+o70/5h3+S+WERIkHVsOXbYhoNC2GLP89M8u7QxQWVCxOj 4AZdpjxhuBm9jMEoUWeYp9PQw8MTs7vAdUSmWIRCE8zM4f28snkA7GZQ6/QNJmKg1YPa EeBY50KLUzSIFT/JYsT8EZ8Rz2Z3D8cRnvQE64oEyhc7GfmEHZOAoyr827brp8c0ymw1 AE60B62x+DyfcpqK/TIGB4fsMqW80mW9YH/bqdvjcLZx+yVqVNX+tNpaRIuv8KxnUBtG mNMSa3bJ0YaM4pPezeMZKA5Cr5KcyDzapGyXNm14OYoJ6LpDW+P8zorslG+pa+auMfue NaTQ== Received: by 10.14.220.70 with SMTP id n46mr17066093eep.42.1345616436952; Tue, 21 Aug 2012 23:20:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.96.10 with HTTP; Tue, 21 Aug 2012 23:20:06 -0700 (PDT) In-Reply-To: <503314DB.8060902@gmail.com> References: <50215125.6090807@gmail.com> <5024D8C8.9090904@gmail.com> <503314DB.8060902@gmail.com> From: Jason Eisner Date: Wed, 22 Aug 2012 02:20:06 -0400 X-Google-Sender-Auth: IgPWEo2kB4hxfCSJUio6w7KQZFE Message-ID: Subject: Re: bug#12130: Fwd: bug#12130: "sudo make install" applies umask to new directories To: Peter Johansson Content-Type: multipart/alternative; boundary=047d7b621ca6ba7fbc04c7d4bde1 X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 12130 Cc: 12130@debbugs.gnu.org, Stefano Lattarini X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) --047d7b621ca6ba7fbc04c7d4bde1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 21, 2012 at 12:55 AM, Peter Johansson wrote: > On 08/21/2012 02:46 PM, Jason Eisner wrote: > >> Better idea: >> >> Have default 644 for files and 755 for directories, but let the user >> override this by explicitly specifying any of >> * the desired file permissions >> * the desired directory permissions for newly created directories >> * the desired group owner for newly created files and directories >> via command-line options on "make install". >> >> >> You can already do this. You can, e.g., install packages with > > make install MKDIR_P="mkdir -p -m 700" > Good! So then, why not correct the default for new directories to 755, as originally proposed? cheers, jason --047d7b621ca6ba7fbc04c7d4bde1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 21, 2012 at 12:55 AM, Peter Johansso= n <trojkan@gmail.com> wrote:
On 08/21/2012 02:46 PM, Jason Eisner wrote:
Better idea:

Have default 644 for files and 755 for directories, but let the user overri= de this by explicitly specifying any of
* the desired file permissions
* the desired directory permissions for newly created directories
* the desired group owner for newly created files and directories
via command-line options on "make install".


You can already do this. You can, e.g., install packages with

make install MKDIR_P=3D"mkdir -p -m 700"
Good!=A0 So then, why not correct the default for new directories to 755, = as originally proposed?

cheers, jason
--047d7b621ca6ba7fbc04c7d4bde1-- From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 14 05:32:16 2012 Received: (at submit) by debbugs.gnu.org; 14 Sep 2012 09:32:16 +0000 Received: from localhost ([127.0.0.1]:33070 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TCSFz-0002xZ-JS for submit@debbugs.gnu.org; Fri, 14 Sep 2012 05:32:16 -0400 Received: from eggs.gnu.org ([208.118.235.92]:42518) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TCSFx-0002xS-3H for submit@debbugs.gnu.org; Fri, 14 Sep 2012 05:32:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCSEw-0007Ey-L2 for submit@debbugs.gnu.org; Fri, 14 Sep 2012 05:31:16 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_HI,RCVD_NUMERIC_HELO autolearn=ham version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:58161) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCSEw-0007Eo-Hx for submit@debbugs.gnu.org; Fri, 14 Sep 2012 05:31:10 -0400 Received: from eggs.gnu.org ([208.118.235.92]:38049) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCSEq-00018y-HW for bug-automake@gnu.org; Fri, 14 Sep 2012 05:31:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TCSEp-0007Bg-Ac for bug-automake@gnu.org; Fri, 14 Sep 2012 05:31:04 -0400 Received: from plane.gmane.org ([80.91.229.3]:49336) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TCSEp-0007BX-3s for bug-automake@gnu.org; Fri, 14 Sep 2012 05:31:03 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TCSDr-0000mc-EV for bug-automake@gnu.org; Fri, 14 Sep 2012 11:31:03 +0200 Received: from 177.65.231.116 ([177.65.231.116]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Sep 2012 11:30:03 +0200 Received: from diogofsr by 177.65.231.116 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 14 Sep 2012 11:30:03 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-automake@gnu.org From: didi Subject: Re: bug#12130: Fwd: bug#12130: "sudo make install" applies umask to =?utf-8?b?bmV3CWRpcmVjdG9yaWVz?= Date: Fri, 14 Sep 2012 09:29:03 +0000 (UTC) Lines: 25 Message-ID: References: <50215125.6090807@gmail.com> <5024D8C8.9090904@gmail.com> <503314DB.8060902@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 177.65.231.116 (Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0.1) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 208.118.235.17 X-Spam-Score: -5.7 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.7 (-----) Peter Johansson gmail.com> writes: > > On 08/21/2012 02:46 PM, Jason Eisner wrote: > > Better idea: > > > > Have default 644 for files and 755 for directories, but let the user > > override this by explicitly specifying any of > > * the desired file permissions > > * the desired directory permissions for newly created directories > > * the desired group owner for newly created files and directories > > via command-line options on "make install". > > > > > You can already do this. You can, e.g., install packages with > > make install MKDIR_P="mkdir -p -m 700" Unfortunately this doesn't seem to work properly, as the parent directories still retain the permissions of the user. $ mkdir -p -m 755 foo/bar drwx------ foo/ drwxr-xr-x bar/ From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 16 19:59:11 2012 Received: (at 12130) by debbugs.gnu.org; 16 Sep 2012 23:59:12 +0000 Received: from localhost ([127.0.0.1]:37829 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDOk3-00067S-6w for submit@debbugs.gnu.org; Sun, 16 Sep 2012 19:59:11 -0400 Received: from mail-pz0-f44.google.com ([209.85.210.44]:36106) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDOk0-00067K-TT for 12130@debbugs.gnu.org; Sun, 16 Sep 2012 19:59:09 -0400 Received: by dadf8 with SMTP id f8so3794249dad.3 for <12130@debbugs.gnu.org>; Sun, 16 Sep 2012 16:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/O1eoxmO8VtiVN/LJdmOQiliuuk3a3v47/Yy4zmz+MY=; b=EvMR6UytFd/WlIg0JH+AKiPMY1GImNYpEGKk1sz+OXUBPyRSv2RbXYVEwO/CL0qk52 htC7sfsdvzCidsNBD4fVHtuaxGyCFUxW1AeydpvNi0euDWJkFzr36tPYseta/4z+7j6m SFbNU5sI3QHpzz77N0lmZ15upERlRpZDeSyd1BeNuznn62CTzX2bKDRy5XvdMlenpsAT AKo7oJjz2QCukfe/0Dj6E9U0TFDh+YUrCS49YBg2/nHzbLKdKuwqV9HjlOIgBALV+8Yz xEGAG4b74DIb1vYMST3fVs9mle8SIkErGF0drtUfpC1uF2l+fU62Bo3GHri8wo/9f3td 28uA== Received: by 10.66.74.196 with SMTP id w4mr16723180pav.32.1347839877004; Sun, 16 Sep 2012 16:57:57 -0700 (PDT) Received: from [152.98.48.237] (gateway.qimr.edu.au. [152.98.8.1]) by mx.google.com with ESMTPS id pn4sm5902668pbb.50.2012.09.16.16.57.54 (version=SSLv3 cipher=OTHER); Sun, 16 Sep 2012 16:57:56 -0700 (PDT) Message-ID: <50566690.3030801@gmail.com> Date: Mon, 17 Sep 2012 09:53:52 +1000 From: Peter Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.7) Gecko/20120825 Thunderbird/10.0.7 MIME-Version: 1.0 To: didi Subject: Re: bug#12130: Fwd: bug#12130: "sudo make install" applies umask to new directories References: <50215125.6090807@gmail.com> <5024D8C8.9090904@gmail.com> <503314DB.8060902@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 12130 Cc: 12130@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) [CC coreutils this is http://lists.gnu.org/archive/html/bug-automake/2012-08/msg00001.html] On 09/14/2012 07:29 PM, didi wrote: >> You can already do this. You can, e.g., install packages with >> > >> > make install MKDIR_P="mkdir -p -m 700" > Unfortunately this doesn't seem to work properly, as the parent directories > still retain the permissions of the user. > > $ mkdir -p -m 755 foo/bar > > drwx------ foo/ > drwxr-xr-x bar/ > > > > Hi Didi, That was unexpected and unfortunate IMVHO. I see the same behaviour on my local system, in other words, mkdir -p -m 700 /tmp/foo/bar creates bar with permissions 700 and bar with 776 (my umask). I wonder is that behaviour is mandated by some standard or if there is room for improvement in coreutils here (CC:ed). Thanks, Peter From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 17 08:45:24 2012 Received: (at control) by debbugs.gnu.org; 17 Sep 2012 12:45:24 +0000 Received: from localhost ([127.0.0.1]:38607 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDahX-0002Yt-OE for submit@debbugs.gnu.org; Mon, 17 Sep 2012 08:45:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5869) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TDahR-0002Ya-Qc; Mon, 17 Sep 2012 08:45:20 -0400 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8HCi27s011357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Sep 2012 08:44:02 -0400 Received: from [10.3.113.22] (ovpn-113-22.phx2.redhat.com [10.3.113.22]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q8HCi1I7009156; Mon, 17 Sep 2012 08:44:02 -0400 Message-ID: <50571B10.30501@redhat.com> Date: Mon, 17 Sep 2012 06:44:00 -0600 From: Eric Blake Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0 MIME-Version: 1.0 To: Peter Johansson Subject: Re: bug#12130: Fwd: bug#12130: "sudo make install" applies umask to new directories References: <50215125.6090807@gmail.com> <5024D8C8.9090904@gmail.com> <503314DB.8060902@gmail.com> <50566690.3030801@gmail.com> In-Reply-To: <50566690.3030801@gmail.com> X-Enigmail-Version: 1.4.4 OpenPGP: url=http://people.redhat.com/eblake/eblake.gpg Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigC088972C74C9978C0A78C023" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Spam-Score: -7.4 (-------) X-Debbugs-Envelope-To: control Cc: 12130-done@debbugs.gnu.org, coreutils@gnu.org, didi X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -7.4 (-------) This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC088972C74C9978C0A78C023 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable tag 12130 notabug thanks On 09/16/2012 05:53 PM, Peter Johansson wrote: > mkdir -p -m 700 /tmp/foo/bar >=20 > creates bar with permissions 700 and bar with 776 (my umask). I wonder > is that behaviour is mandated by some standard Yes - POSIX requires this: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mkdir.html -p Create any missing intermediate pathname components. For each dir operand that does not name an existing directory, effects equivalent to those caused by the following command shall occur: mkdir -p -m $(umask -S),u+wx $(dirname dir) && mkdir [-m mode] dir where the -m mode option represents that option supplied to the original invocation of mkdir, if any. > or if there is room for > improvement in coreutils here (CC:ed). Since POSIX requires the existing behavior, there's unfortunately no room for improvement, and I'm closing this as not a bug in coreutils. --=20 Eric Blake eblake@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --------------enigC088972C74C9978C0A78C023 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQEcBAEBCAAGBQJQVxsRAAoJEKeha0olJ0NqsMYH/RQ0Z2Bc8jSXF+0pumGKmv48 4tASjXaoLFZhy9GmmBOM84EF64NZQyVSr/Zls6b7U4o9nnKFDGwJaimam21jbXMJ uLrFviTXPX5zmaCDV4iaUGaLQ2VK9R0IVbWbrPzXdbDtZpDiVBz2gdjXfkE2H2fN vV83VrFa5IEYk7Xc/7ysXncHOGDwA26fMzee4bqhVOhCm5a/uFlZmu7VCIaK9u9d diI1bSe8cf8zYpU3yRMiTLvBEW/Nlf74/SpCehHa5kjCUZepzsA/gJWO7J9dxk7y yzx2LAJvEgAzChwl3Bbh4UGOssCCmO4+KU4l6ARM3Uc+os7/lrEDt1rnVZcP/QY= =IhY7 -----END PGP SIGNATURE----- --------------enigC088972C74C9978C0A78C023-- From unknown Sun Jun 22 11:38:35 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 16 Oct 2012 11:24:03 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator