Production installer fails with umask 077 #2373
Comments
|
Sounds good; I think we just need to add that line near the top of scripts/lib/install and then test it to make sure we did it right :) |
|
@timabbott I would like to work on this. |
|
Cool. Basically you'll just want to do a series of production installs on a VM, using |
|
A quick test looks like that solves the problem. I'll do a more thorough one creating tarballs to confirm. Without any changes, using umask 077 I get this error on a new install: |
|
Cool! Just submit a PR with the change once you've confirmed. Yay, it'll be nice to close this out. |
feorlen
pushed a commit
to feorlen/zulip
that referenced
this issue
Apr 18, 2017
Follow-on from zulip#2373/ PR zulip#4316, to set an appropriate umask also when upgrading. From experimentation, it seems `create-production-venv` is the only part that needs this. If that's not correct, then any other `subprocess.check_call` can have the same preexec_fn added. The permissions do propagate down child subprocesses, but in this case we can't take advantage of that and use it in `lib/upgrade-zulip`, because that isn't updated before being used like `upgrade-zulip-stage-2` is. If in the future it matters, preexec_fn doesn't work for Windows. Also, the lambda is because normally it won't accept a function with arguments. I've tested this by starting from a clean install, deleting /srv/* so new files are downloaded, and then doing an upgrade. It would be nice if someone else can also test this in a production environment to verify I've not missed anything.
feorlen
pushed a commit
to feorlen/zulip
that referenced
this issue
Apr 18, 2017
Follow-on from zulip#2373/ PR zulip#4316, to set an appropriate umask also when upgrading. From experimentation, it seems `create-production-venv` is the only part that needs this. If that's not correct, then any other `subprocess.check_call` can have the same preexec_fn added. The permissions do propagate down child subprocesses, but in this case we can't take advantage of that and use it in `lib/upgrade-zulip`, because that isn't updated before being used like `upgrade-zulip-stage-2` is. If in the future it matters, preexec_fn doesn't work for Windows. Also, the lambda is because normally it won't accept a function with arguments. I've tested this by starting from a clean install, deleting /srv/* so new files are downloaded, and then doing an upgrade. It would be nice if someone else can also test this in a production environment to verify I've not missed anything.
feorlen
pushed a commit
to feorlen/zulip
that referenced
this issue
Apr 18, 2017
Follow-on from zulip#2373/ PR zulip#4316, to set an appropriate umask also when upgrading. From experimentation, it seems `create-production-venv` is the only part that needs this. If that's not correct, then any other `subprocess.check_call` can have the same preexec_fn added. The permissions do propagate down child subprocesses, but in this case we can't take advantage of that and use it in `lib/upgrade-zulip`, because that isn't updated before being used like `upgrade-zulip-stage-2` is. If in the future it matters, preexec_fn doesn't work for Windows. Also, the lambda is because normally it won't accept a function with arguments. I've tested this by starting from a clean install, deleting /srv/* so new files are downloaded, and then doing an upgrade. It would be nice if someone else can also test this in a production environment to verify I've not missed anything.
feorlen
pushed a commit
to feorlen/zulip
that referenced
this issue
Apr 18, 2017
Follow-on from zulip#2373/ PR zulip#4316, to set an appropriate umask also when upgrading. From experimentation, it seems create-production-venv is the only part that needs this. If that's not correct, then any other subprocess.check_call can have the same preexec_fn added. The permissions do propagate down child subprocesses, but in this case we can't take advantage of that and use it in lib/upgrade-zulip, because that isn't updated before being used like upgrade-zulip-stage-2 is. If in the future it matters, preexec_fn doesn't work for Windows. Also, the lambda is because normally it won't accept a function with arguments. I've tested this by starting from a clean install, deleting /srv/* so new files are downloaded, and then doing an upgrade. It would be nice if someone else can also test this in a production environment to verify I've not missed anything.
feorlen
pushed a commit
to feorlen/zulip
that referenced
this issue
Apr 19, 2017
Follow-on from zulip#2373/ PR zulip#4316, to set an appropriate umask also when upgrading. From experimentation, it seems create-production-venv is the only part that needs this. If that's not correct, then any other subprocess.check_call can have the same preexec_fn added. The permissions do propagate down child subprocesses, but in this case we can't take advantage of that and use it in lib/upgrade-zulip, because that isn't updated before being used like upgrade-zulip-stage-2 is. If in the future it matters, preexec_fn doesn't work for Windows. Also, the lambda is because normally it won't accept a function with arguments. I've tested this by starting from a clean install, deleting /srv/* so new files are downloaded, and then doing an upgrade. It would be nice if someone else can also test this in a production environment to verify I've not missed anything.
feorlen
pushed a commit
to feorlen/zulip
that referenced
this issue
Apr 19, 2017
Follow-on from zulip#2373/ PR zulip#4316, to set an appropriate umask also when upgrading so files have appropriate permissions. I've tested this by starting from a clean install, deleting /srv/* so new files are downloaded, and then doing an upgrade. It worked starting with both a current version from master and an older release installed with a less restrictive umask and then the umask changed. Fixes zulip#2373
brockwhittaker
pushed a commit
to brockwhittaker/zulip
that referenced
this issue
May 1, 2017
Follow-on from zulip#2373/ PR zulip#4316, to set an appropriate umask also when upgrading so files have appropriate permissions. I've tested this by starting from a clean install, deleting /srv/* so new files are downloaded, and then doing an upgrade. It worked starting with both a current version from master and an older release installed with a less restrictive umask and then the umask changed. Fixes zulip#2373.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Running the production installer under
umask 077fails with permission errors, because, e.g., /srv/zulip-venv-cache becomes readable only by root. It should probablyumask 022near the top.The text was updated successfully, but these errors were encountered: