Opened 18 years ago
Closed 3 years ago
#4282 closed Bug (fixed)
startproject should honor umask
Reported by: | Owned by: | Ad Timmering | |
---|---|---|---|
Component: | Core (Management commands) | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Ad Timmering, Claude Paroz | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Ticket #1651 fixed the problem of manage.py not being made executable by copying *all* the permission bits (not just the executable flags). This means that the user's umask doesn't work, e.g.:
$ umask 077 $ touch foo $ ls -l foo -rw------- 1 talex talex 0 2007-05-12 13:27 foo $ PYTHONPATH=trunk ./trunk/django/bin/django-admin.py startproject mysite $ ls -l mysite/settings.py -rw-r--r-- 1 talex talex 2804 2007-05-12 13:28 mysite/settings.py
I discovered this whilst trying to make a Zero Install package for Django. Everything in the Zero Install cache is read-only, so startproject fails with:
File "/var/cache/0install.net/implementations/sha1new=262c95b5a7cc34f525408b675106e4e4ae3494cc/django/core/management.py", line 799, in startproject fp = open(main_settings_file, 'w') IOError: [Errno 13] Permission denied: '.../site/settings.py'
Thanks,
Attachments (3)
Change History (25)
comment:1 by , 18 years ago
Summary: | startproject doesn't honour umask → startproject should honour umask |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 18 years ago
Summary: | startproject should honour umask → startproject should honor umask |
---|
comment:3 by , 17 years ago
Has patch: | set |
---|
comment:5 by , 17 years ago
The patch doesn't apply any more (the relevant code is now in django/core/management/base.py). I've adapted the patch, but I'm not sure how this should interact with the _make_writeable call. I'll upload the updated patch anyway, just in case.
comment:7 by , 14 years ago
Severity: | → Normal |
---|---|
Type: | → New feature |
by , 13 years ago
Attachment: | 4282_against_16741.diff added |
---|
comment:8 by , 13 years ago
Easy pickings: | unset |
---|---|
UI/UX: | unset |
Confirmed issue still exists in r16741. This patch applies cleanly and fixes the issue.
comment:9 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:10 by , 11 years ago
I uploaded & updated the pull request. https://github.com/django/django/pull/2061
would be great if somebody will making suggestions.
comment:12 by , 3 years ago
Cc: | added |
---|
comment:13 by , 3 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
(de-assigning as not touched in 8 years)
comment:14 by , 3 years ago
Cc: | added |
---|
Hey Adam — thanks for looking!
Seems like the behaviour is unchanged (to 4.0b1):
% mkdir issue4282 % cd issue4282 issue4282 % umask 077 issue4282 % touch foo issue4282 % ls -l foo -rw------- 1 carlton staff 0 Nov 16 10:06 foo issue4282 % django-admin startproject mysite issue4282 % ls -l mysite/mysite/settings.py -rw-r--r-- 1 carlton staff 3221 Nov 16 10:06 mysite/mysite/settings.py issue4282 % django-admin --version 4.0b1
Expected behaviour is that the created files have the restricted permissions, I think.
The original patch didn't look too complex… 🤔 (We do similar in storage.py — I didn't look into Claude's comments on the PR there.)
It may be that if we're not going to fix this, we can mark it wontfix. (Is this something Django needs to handle that a find ... | xargs chmod
wouldn't be more appropriate for?)
comment:15 by , 3 years ago
Thanks for context Claude.
I have started a PR based on the original.
What has changed since the original is that django-admin is now called with subprocess.run()
, where setting umask
is only possibly since 3.9. (Discussion on introduction of umask
and [lack of] alternatives at https://bugs.python.org/issue38417).
Would it be OK to write the tests so they are only run on >=3.9 ?
I'll try and fix the PR to reflect that first and flag it ready for review once done.
comment:16 by , 3 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:17 by , 3 years ago
Still need to fix the PR for Windows (checking hasattr(os, 'umask')
doesn't cut it), but keen to know if PR is directionally fine.
comment:18 by , 3 years ago
Patch needs improvement: | unset |
---|
Modified and tests pass- but as said in previous comment, tests are skipped on Python 3.8 as it does not support setting umask
in subprocess.run()
so we can't test.
comment:19 by , 3 years ago
Patch needs improvement: | set |
---|
comment:20 by , 3 years ago
Patch needs improvement: | unset |
---|
Thanks for the review Mariusz, learning from your comments. Applied the changes.
comment:21 by , 3 years ago
Triage Stage: | Accepted → Ready for checkin |
---|---|
Type: | New feature → Bug |
Seems like a good improvement to me. A patch would be great.