-
Notifications
You must be signed in to change notification settings - Fork 91
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
Chmod on directories has no effect on readability #496
Comments
Thanks for the report! This case is indeed not implemented, and has not been noticed so far. |
I can reproduce the |
Thanks for the quick response! I am running macOS |
Hm, actually I cannot reproduce any of these problems under Linux (in the Travis environment, as non-root user). I can reproduce all but the |
@ian-h-chamberlain - just to make sure: did you make these tests also on the real filesystem? Especially under Linux? |
I'm sorry, I have not seen such a thing.
…On Sat, Oct 12, 2019 at 10:18 AM mrbean-bremen ***@***.***> wrote:
@ian-h-chamberlain <https://github.com/ian-h-chamberlain> - just to make
sure: did you make these tests also on the real filesystem? Especially
under Linux?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#496>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AA4MWAJ7VGRTAUPOXMFPFZLQOIBFDANCNFSM4I7A4COA>
.
|
@mrbean-bremen – my apologies, it seems my test was incomplete – Here is a revised version, I was able to reproduce within a Linux container (don't have access to a real linux machine atm) as well as on macOS 10.14.6: """Minimal reproduction of directory permissions issues"""
import os
import pathlib
import stat
import pytest
_PATH = os.path.dirname(__file__) + "/test_dir"
@pytest.fixture(params=[pytest.param(True, id="real_fs"), pytest.param(False, id="fake_fs")])
def unreadable_dir(request, fs):
use_real_fs = request.param
if use_real_fs:
fs.pause()
else:
fs.create_file(_PATH + "/file")
os.chmod(_PATH, 0o000)
yield fs
fs.resume()
def test_read_dir_os(unreadable_dir):
with pytest.raises(OSError):
os.listdir(_PATH) # Does not raise
with pytest.raises(OSError):
os.stat(_PATH + "/file") # Does not raise
def test_dir_permissions_os(unreadable_dir):
assert stat.S_IMODE(os.stat(_PATH).st_mode) == 0o000
def test_read_dir_pathlib(unreadable_dir):
path = pathlib.Path(_PATH)
with pytest.raises(OSError):
list(path.iterdir()) # Does not raise
with pytest.raises(OSError):
(path / "file").stat() # Does not raise
def test_dir_permissions_pathlib(unreadable_dir):
path = pathlib.Path(_PATH)
assert stat.S_IMODE(path.stat().st_mode) == 0o000 Output:
Docker command shows the same output:
|
Hm, as I said - I can reproduce the behavior under MacOS, but not under Linux (in Travis). Your tests look good, so there has to be some reason for the different behavior under Linux... EDIT: If possible, it would be nice if you could test the aforementioned branch under MacOS. I'm not sure if the changes are sufficient. |
- changes are for MacOS only, as long as Linux behavior is unclear - see pytest-dev#496
@ian-h-chamberlain - I added a PR with the changes (MacOS only, as I wrote), maybe you can check it out. |
- changes are for MacOS only, as long as Linux behavior is unclear - see #496
@mrbean-bremen Sorry for the delay. I was able to test on Linux and as far as I can tell the behavior is the same as on macOS for me – my test fails in the same way:
The error number in the assert excinfo.value.errno == errno.EACCES in each test case where an error is expected.
Hope this helps, I'm not sure why you're not able to reproduce this on your system (perhaps CentOS handles this differently than the Linux distro in your CI)? |
Second bit – my test fails on macOS using latest `master as well:
As far as I can tell, macOS (and Linux for that matter) default behavior is to allow |
Hm, thanks for the information! The CI build is using Ubuntu 16.04. I may try to change that and test other systems, but as long as I don't understand where the difference comes from, I won't change it in the code. Maybe there is some setting that differs... I actually would have expected the behavior you describe, at least for |
Ok, didn't see your second post about MacOS - this looks like a bug I did introduce. I agree that |
- changes are for MacOS only, as long as Linux behavior is unclear - see #496
I did some branch mixup, but it shall be fixed now for MacOs. |
@ian-h-chamberlain - just to let you know: I tried the same with a CentOs docker image, and got the same behavior you got. So at least CentOS and Ubuntu seem to behave differently in this respect. I think I will test with some other systems later, though that may take some time (I won't have time/access to a computer at least until next month). |
Ok, I just found out that probably the behavior does not depend on the distribution, but on the fact that the test is run in a docker container. Running the tests in an Ubuntu docker container shows the same behavior as for CentOs. This is a bit unfortunate, as I don't know how to test other systems not in a docker image - both Travis.CI and GitHub actions use Ubuntu images only. I know that inodes behave differently in a docker image for some reason, and I could adapt the behavior to be dependent on them running in a docker image. What this also means is that you should probably not rely on this kind of behavior if you want to have portable code. |
Due to #500 some of the results may not be valid... |
- enable for Linux, disable for root users - see pytest-dev#496
Ok, sorry for all the confusion - all my tests have been void due to an incorrect Travis.CI script that does not fail the build if one of the test runs (except the last) fails. As the last test under Linux (but not under MacOS and not in a docker container) was running as a root user, the behavior was different here... |
- enable for Linux, disable for root users - see #496
Shall be fixed now - please re-open if something is missing. |
That was some fine work on a difficult problem, @mrbean-bremen. Very well done. |
Thanks - though this was an error of my own making - didn't think about error propagation while writing the test script for Travis... |
Describe the bug
After creating a directory with files in it in the fake filesystem, then changing its permissions to disallow
r/w/x
, it is still possible to read the contents of the directory.In a real filesystem, a directory with perms
000
would raisePermissionsError
when attempting to read the directory contents.This is not an instance of #489 – these tests still fail even when run as non-root user.
How To Reproduce
Your enviroment
The same symptoms seem to occur when tested on platform
The text was updated successfully, but these errors were encountered: