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

Surpress chmod warnings #47

Closed
wants to merge 1 commit into from
Closed

Surpress chmod warnings #47

wants to merge 1 commit into from

Conversation

peterrehm
Copy link

See doctrine/common#381

This avoids the error chmod(): Operation not permitted when your current user has not created the file but is in the same group.

@Ocramius
Copy link
Owner

This requires testing though

@peterrehm
Copy link
Author

I expected no other response, but when chmod was introduced with faf066e there was also no test?

How would you like it to be tested?

@Ocramius
Copy link
Owner

Ocramius commented Sep 21, 2017 via email

@Ocramius
Copy link
Owner

Ocramius commented Sep 21, 2017 via email

@peterrehm
Copy link
Author

Hehe 😄

As this more or less reverts the previous change or at least does not throw an exception when the chmod breaks I think this could be accepted without the overhead of a full E2E test.

This is no functionality just the supression of errors.

What do you think?

@Ocramius
Copy link
Owner

Ocramius commented Sep 21, 2017 via email

@peterrehm
Copy link
Author

Okay, then feel free to close the PR.

@Ocramius
Copy link
Owner

@peterrehm I'm fine with keeping it open until somebody else comes up with a valid test scenario ;-)

@peterrehm
Copy link
Author

Btw. another solution would have been deleting the file prior to the chown.

@peterrehm
Copy link
Author

And this is the reason for the issue: https://unix.stackexchange.com/a/125787

@@ -124,7 +124,7 @@ private static function writeVersionClassToFile(string $versionClassSource, Comp
$io->write('<info>ocramius/package-versions:</info> Generating version class...');

file_put_contents($installPath, $versionClassSource);
chmod($installPath, 0664);
@chmod($installPath, 0664);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this really be silenced without an error message? It doesn't feel right.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's what the test would find out. IMO, since this is a CLI script modifying the data, it should probably not be silenced, but rather crash hard.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Hard" as in \RuntimeException and a $io->write('<error>ocramius/package-versions: You ruined my life!!1!</error>') before the exception?

Copy link

@morozov morozov Nov 27, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't file_put_contents() just rely on what's defined by umask? Like:

↪ umask 
0002

↪ php -r 'file_put_contents("foo", "bar");'

↪ ls -l foo
-rw-rw-r-- 1 morozov morozov 3 Nov 27 12:51 foo

Is there a reason why the installer wants to enforce particular permissions in the first place?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So if I set umask 0 and run composer install, then the resulting files look like this:

↪  ls -l vendor/ocramius/package-versions/src/PackageVersions/
total 20
-rw-rw-rw- 1 morozov morozov 2582 Sep  6 08:24 FallbackVersions.php
-rw-rw-rw- 1 morozov morozov 5468 Sep  6 08:24 Installer.php
-rw-rw-r-- 1 morozov morozov 4558 Nov 27 23:06 Versions.php

The auto-generated file is indeed not writable by others but the rest of the files are. The attacker still can write code into other files.

@peterrehm
Copy link
Author

It has been fixed thiws way e.g. in Twig:

twigphp/Twig#705

Another option would be to remove the file prior to writing it, a user in the same group can do this and afterwards the file has the current user as the owner and a chmod is permitted.

Prior to introducing the chmod command I had no issues.

@Ocramius
Copy link
Owner

Ocramius commented Sep 22, 2017 via email

@Ocramius
Copy link
Owner

Ocramius commented Nov 28, 2017 via email

@peterrehm
Copy link
Author

I am closing this as it looks like this wont be fixed.

@Ocramius
Copy link
Owner

@peterrehm thanks for the feedback anyway!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants