Skip to content

Test test_filelock.py::test_lock_mode_soft fails if default umask is 002 #223

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

Closed
TheMatt2 opened this issue Apr 6, 2023 · 1 comment · Fixed by #227
Closed

Test test_filelock.py::test_lock_mode_soft fails if default umask is 002 #223

TheMatt2 opened this issue Apr 6, 2023 · 1 comment · Fixed by #227

Comments

@TheMatt2
Copy link
Contributor

TheMatt2 commented Apr 6, 2023

Description

Test cases for filelock fail if the umask of the current user is not 022.
This is a problem, because it seems the default umask for Ubuntu 22.10 seems to be 002.

I can see documentation showing it should be 002. I know this is odd, as I was expecting it to be 002.

From /etc/login.defs

#
# Enable setting of the umask group bits to be the same as owner bits
# (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is
# the same as gid, and username is the same as the primary group name.
#
# If set to yes, userdel will remove the user's group if it contains no
# more members, and useradd will create by default a group with the name
# of the user.
#
USERGROUPS_ENAB yes

This leads to the error in testing:

python3 -m pytest
====================================================== test session starts =======================================================
platform linux -- Python 3.10.7, pytest-7.2.2, pluggy-1.0.0
rootdir: .../py-filelock
plugins: cov-4.0.0, timeout-2.1.0, mock-3.10.0
collected 50 items                                                                                                               

tests/test_error.py ....                                                                                                   [  8%]
tests/test_filelock.py ........................................F.....                                                      [100%]

============================================================ FAILURES ============================================================
______________________________________________________ test_lock_mode_soft _______________________________________________________

tmp_path = PosixPath('.../pytest-4/test_lock_mode_soft0')

    def test_lock_mode_soft(tmp_path: Path) -> None:
        lock_path = tmp_path / "a.lock"
        lock = SoftFileLock(str(lock_path), mode=0o666)
    
        lock.acquire()
        assert lock.is_locked
    
        mode = filemode(os.stat(lock_path).st_mode)
        if sys.platform == "win32":
            assert mode == "-rw-rw-rw-"
        else:
>           assert mode == "-rw-r--r--"
E           AssertionError: assert '-rw-rw-r--' == '-rw-r--r--'
E             - -rw-r--r--
E             + -rw-rw-r--

tests/test_filelock.py:447: AssertionError
==================================================== short test summary info =====================================================
FAILED tests/test_filelock.py::test_lock_mode_soft - AssertionError: assert '-rw-rw-r--' == '-rw-r--r--'
================================================== 1 failed, 49 passed in 1.65s ==================================================

Steps to Reproduce

  1. Set umask umask 002
  2. Run pytest against repo
  3. Observe errrors

Expected behavior

Test cases should either skip or force the umask to make sure everything is working correctly.

@TheMatt2 TheMatt2 changed the title Test test_filelock.py::test_lock_mode_soft fails is default umask is 002 Test test_filelock.py::test_lock_mode_soft fails if default umask is 002 Apr 6, 2023
@TheMatt2
Copy link
Contributor Author

TheMatt2 commented Apr 7, 2023

Perhaps there should be clearer documentation that Filelock sets permissions regardless of umask, and SoftFilelock sets permissions using umask? Perhaps changing this behavior?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant