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

Improve Setting Permissions of Created Files #2525

Merged
merged 8 commits into from
May 5, 2021

Conversation

felixhandte
Copy link
Contributor

This PR is a follow-up to issues #1630 and #2491 (and their associated PRs #1644 and #2495).

This stack starts by adding tests to (a) codify the expected behavior (which is at present poorly defined) and (b) enforce that zstd implements that behavior.

I expect, once we've settled on the desired behavior, to refactor how zstd sets permissions on created files. In particular, I expect to switch to the open() + fdopen() pattern suggested in the bug report and possibly remove the trailing chmod() (if we can get the permissions right from the start, why wait until the end to set them?).

@felixhandte felixhandte force-pushed the fix-file-permissions-again branch 2 times, most recently from 632dd36 to 3dd0e9d Compare March 8, 2021 23:17
@felixhandte felixhandte changed the title WIP: Improve Handling of Permissions for Created Files Improve Setting Permissions of Created Files Mar 8, 2021
@flx42
Copy link

flx42 commented Apr 5, 2021

Hello!

When compressing from stdin, we were a bit surprised to discover than the behavior of zstd changed on Ubuntu 20.04 as a result of CVE-2021-24031 being fixed in security package update 1.4.4+dfsg-3ubuntu0.1. Before this fix, the output file would be created as 0666. With the new package version, the file is created as 0600.

Looks like this PR restores the previous behavior when compressing from stdin, so it would be great to have for us. Our current workaround will be to manually chmod the output file, but we might also build a new release of zstd with this patch, if it gets accepted.

@Cyan4973
Copy link
Contributor

Cyan4973 commented Apr 5, 2021

The fuzz sanitizer test failures are unrelated to this PR.

But there are still some issues left on Windows :
https://ci.appveyor.com/project/YannCollet/zstd-p0yf0/builds/38127695/job/xvecnmj07lttm64l#L252

@@ -209,7 +209,7 @@ println "test : compress to stdout"
zstd tmp -c > tmpCompressed
zstd tmp --stdout > tmpCompressed # long command format
println "test : compress to named file"
rm tmpCompressed
rm -f tmpCompressed
Copy link
Contributor

@Cyan4973 Cyan4973 Apr 7, 2021

Choose a reason for hiding this comment

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

minor:
a variable $RM would be better to propagate this change throughout the script

`open()`'s mode bits are only applied to files that are created by the call.
If the output file already exists, but is not readable, the `fopen()` would
fail, preventing us from removing it, which would mean that the file would
not end up with the correct permission bits.

It's not clear to me why the `fopen()` is there at all. `UTIL_isRegularFile()`
should be sufficient, AFAICT.
I think in some unix emulation environments on Windows, (cygwin?) mode bits
are somehow respected. So we might as well pass them in. Can't hurt.
Copy link
Contributor

@Cyan4973 Cyan4973 left a comment

Choose a reason for hiding this comment

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

My only comment is that
I would have replaced all these rm -f in playTests.sh
by a variable $RM
but that's minor.

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