Skip Menu |
Report information
Id: 123800
Status: open
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: masak <cmasak [at] gmail.com>
Cc:
AdminCc:

Severity: (no value)
Tag: Bug
Platform: (no value)
Patch Status: (no value)
VM: (no value)



To: rakudobug [...] perl.org
From: Carl Mäsak <cmasak [...] gmail.com>
Date: Wed, 11 Feb 2015 20:06:27 +0100
Subject: [BUG] &copy doesn't copy the umask in Rakudo
Download (untitled) / with headers
text/plain 1.1k
<lizmat> $ ls -ls big* <lizmat> 11724800 -rw------- 1 liz macports 6003097600 Feb 11 19:08 big <lizmat> 11724800 -rw-r--r-- 1 liz macports 6003097600 Feb 11 19:11 big2 <masak> by the way, is it intentional (or by spec) that those two files have different umasks? <lizmat> I guess the copy used a different umask <lizmat> $ umask <lizmat> 0022 <lizmat> hmmm... <Juerd> imho copy should force the permissions to be the same, regardless of the umask <Juerd> (When chmod is permitted at all) <moritz> is that what GNU cp does? <Juerd> moritz: Yes: <Juerd> open("a", O_RDONLY) = 3 <Juerd> fstat(3, {st_mode=S_IFREG|0400, st_size=0, ...}) = 0 <Juerd> open("b", O_WRONLY|O_CREAT|O_EXCL, 0400) = 4 <Juerd> 0400 is the mode <Juerd> And that changes if I delete b and chmod a and then do another "strace cp a b" <masak> ok, now I feel like submitting a rakudobug about &copy not setting the umask to the same, like GNU cp does. <lizmat> masak: please do, so it won't fall though the cracks * masak does <lizmat> I'm not sure at which level this should be fixed, though <lizmat> feels to me, MoarVM should be doing the right thing on open
From: Parrot Raiser <1parrota [...] gmail.com>
Date: Wed, 11 Feb 2015 16:21:32 -0500
To: perl6-compiler [...] perl.org
Subject: Re: [perl #123800] [BUG] &copy doesn't copy the umask in Rakudo
Being really pedantic, the files have different "permissions". I'm sure that's what Mazak meant. "Umask" is what is applied to the default permissions, to set the actual permissions when a new file is created. It only relates to the creation, not any subsequent states. Not replicating the original file permissions on a copy would be a huge security hole. Anybody could copy a root-read-only file, examine the contents, modify them, and, if they had write access to the directory, replace it with the updated one. I'm sure I'm teaching the choir "Our Father, &c." with this, but just in case it's not obvious.. On 2/11/15, Carl Mäsak <perl6-bugs-followup@perl.org> wrote: Show quoted text
> # New Ticket Created by "Carl Mäsak" > # Please include the string: [perl #123800] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=123800 > > > > <lizmat> $ ls -ls big* > <lizmat> 11724800 -rw------- 1 liz macports 6003097600 Feb 11 19:08 big > <lizmat> 11724800 -rw-r--r-- 1 liz macports 6003097600 Feb 11 19:11 big2 > <masak> by the way, is it intentional (or by spec) that those two > files have different umasks? > <lizmat> I guess the copy used a different umask > <lizmat> $ umask > <lizmat> 0022 > <lizmat> hmmm... > <Juerd> imho copy should force the permissions to be the same, > regardless of the umask > <Juerd> (When chmod is permitted at all) > <moritz> is that what GNU cp does? > <Juerd> moritz: Yes: > <Juerd> open("a", O_RDONLY) = 3 > <Juerd> fstat(3, {st_mode=S_IFREG|0400, st_size=0, ...}) = 0 > <Juerd> open("b", O_WRONLY|O_CREAT|O_EXCL, 0400) = 4 > <Juerd> 0400 is the mode > <Juerd> And that changes if I delete b and chmod a and then do another > "strace cp a b" > <masak> ok, now I feel like submitting a rakudobug about &copy not > setting the umask to the same, like GNU cp does. > <lizmat> masak: please do, so it won't fall though the cracks > * masak does > <lizmat> I'm not sure at which level this should be fixed, though > <lizmat> feels to me, MoarVM should be doing the right thing on open >
Subject: Re: [perl #123800] [BUG] &copy doesn't copy the umask in Rakudo
To: Parrot Raiser <1parrota [...] gmail.com>
Date: Wed, 11 Feb 2015 15:30:57 -0600
CC: perl6-compiler [...] perl.org
From: "Patrick R. Michaud" <pmichaud [...] pobox.com>
Download (untitled) / with headers
text/plain 913b
On Wed, Feb 11, 2015 at 04:21:32PM -0500, Parrot Raiser wrote: Show quoted text
> Not replicating the original file permissions on a copy would be a > huge security hole. Anybody could copy a root-read-only file, examine > the contents, modify them, and, if they had write access to the > directory, replace it with the updated one.
I think this is overstating things a fair bit. A file that is root-read-only would only be readable by root, not "anybody". Assuming a non-root person has read permissions to a file that is "root-read-only" (whatever that means), there are plenty of ways to create a modifiable copy of that file without using &copy. So &copy itself isn't the source (or fix) of the security hole. Ultimately I agree that the original file permissions should come into play, however. I suspect that &copy should create the new copy with the existing file's permissions as modified by the current umask. Pm


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org