Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

&copy doesn't copy the file attributes in Rakudo #3680

Open
p6rt opened this issue Feb 11, 2015 · 5 comments
Open

&copy doesn't copy the file attributes in Rakudo #3680

p6rt opened this issue Feb 11, 2015 · 5 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Feb 11, 2015

Migrated from rt.perl.org#123800 (status was 'open')

Searchable as RT123800$

@p6rt
Copy link
Author

p6rt commented Feb 11, 2015

From @masak

<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

@p6rt
Copy link
Author

p6rt commented Feb 11, 2015

From 1parrota@gmail.com

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​:

# 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-archive.perl.org/perl6/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

@p6rt
Copy link
Author

p6rt commented Feb 11, 2015

The RT System itself - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Feb 11, 2015

From @pmichaud

On Wed, Feb 11, 2015 at 04​:21​:32PM -0500, Parrot Raiser wrote​:

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

@p6rt p6rt added the Bug label Jan 5, 2020
@JJ
Copy link

JJ commented Jan 4, 2021

This problem goes down to the libuv library that's used. Also, it should probably mention file attributes, not "umask", which is a different thing.

@JJ JJ changed the title &copy doesn't copy the umask in Rakudo &copy doesn't copy the file attributes in Rakudo Jan 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants