8000 Improve Setting Permissions of Created Files by felixhandte · Pull Request #2525 · facebook/zstd · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Improve Setting Permissions of Created Files #2525

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

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
@felixhandte felixhandte force-pushed the fix-file-permissions-again branch from 98468f9 to b924955 Compare March 9, 2021 06:54
@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

@felixhandte felixhandte force-pushed the fix-file-permissions-again branch from b924955 to 08b79af Compare April 5, 2021 21:42
@@ -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.
@felixhandte felixhandte force-pushed the fix-file-permissions-again branch from 14167df to 4f9c6fd Compare May 5, 2021 17:14
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
0