Domanda

I have a directory which I would like to be able to be used by anyone in the group website-development. The owner of the directory is root, and the group is website-development. I've set the permissions to ---rws--- and have also set those permissions on the default acl for the directory with setfacl -dm "u::---,g::rwx,o::---" . I've also added myself to the website-development group, which I had thought would give me full permissions to the directory. However, when I try to run virtualenv website-env to create a virtualenv for the website, I get this error:

Running virtualenv with interpreter /usr/local/bin/python3.3
Using base prefix '/usr/local'
Traceback (most recent call last):
  File "/usr/local/lib/python3.4/site-packages/virtualenv.py", line 2338, in <module>
    main()
  File "/usr/local/lib/python3.4/site-packages/virtualenv.py", line 824, in main
    symlink=options.symlink)
  File "/usr/local/lib/python3.4/site-packages/virtualenv.py", line 984, in create_environment
    site_packages=site_packages, clear=clear, symlink=symlink))
  File "/usr/local/lib/python3.4/site-packages/virtualenv.py", line 1158, in install_python
    mkdir(lib_dir)
  File "/usr/local/lib/python3.4/site-packages/virtualenv.py", line 447, in mkdir
    os.makedirs(path)
  File "/usr/local/lib/python3.3/os.py", line 258, in makedirs
    makedirs(head, mode, exist_ok)
  File "/usr/local/lib/python3.3/os.py", line 269, in makedirs
    mkdir(name, mode)
PermissionError: [Errno 13] Permission denied: 'website-env/lib'

I could run it via sudo but then I have to keep using sudo for every virtualenv-related command. What's causing virtualenv to lack permissions for files it creates?

Edit

The output of ls -la is:

total 8
dr-xrws---+ 2 root website-development 4096 May  6 02:01 .
drwxr-xr-x  3 root root                4096 Apr 16 20:47 ..

The output of groups is:

will wheel website-dev website-development

(The website-dev group is from an older attempt that I haven't gotten around to cleaning up, but I shouldn't think it would affect this)

The output of virtualenv --python=python3.3 -v website-env is identical to the output of virtualenv --python=python3.3 website-env.

The output of virtualenv --version is 1.11.4.

I should perhaps note that I'm running this on CentOS, and so I'm specifying the Python version in the virtualenv commandline to get around the fact that CentOS still ships with and relies on Python 2.6.9.

È stato utile?

Soluzione

The problem is with the way you have set up the acl, specifically the -d flag. This will set the default permissions for new files/directories. In your case, you have set them identical to the access permissions, ---rws---, and when virtualenv makes subdirectories in website-env, they also have these permissions. Actually, I'm not sure why virtualenv cannot write to them the same as writing to website-env, but this is the immediate problem.

To resolve the issue:

Remove all acl controls from website-env. Then run setfacl -m "u::---,g::rwx,o::---" website-env.

$ getfacl website-env
# file: website-env
# owner: root
# group: website-development
flags: -s-
user::---
group::rwx
other::---

virtualenv will now execute correctly.

Optional:

I found that if you want to set the default permissions for new files/directories, they can be added with a second command setfacl -m "d:u::rwx,d:g::rwx,d:o::---" website-env.

$ getfacl website-env
...
...
default:user::rwx
default:group::rwx
default:other::---

These appear to be the minimal permissions required for virtualenv to execute. New directories are created with permissions rwxrws---. You may be able to fine tune this better through the use of the mask setting, but I don't know much about that.

Edit

It definitely appears that setting the user permissions to --- is overriding the group permissions set to rwx:

d---rws---+  2 root  group 4.0K May  6 02:09 dir1
d---rws---+  2 user  group 4.0K May  6 02:09 dir2

user:~$ touch dir1/foo && ls dir1
foo
user:~$ touch dir2/foo && ls dir2
touch: cannot touch 'dir2/foo': Permission denied

It's interesting that I can access a directory owned by root, as long as I'm a member of group, but I cannot access a directory owned by me, despite being a member of the same group and having group class permissions. Apparently the owners' permissions take precedence, and if they are set to --- he cannot modify his files, even though others in the group can!

What is happening in your case: website-env is owned by root. The group website-development has full access to it. When you run virtualenv, subdirectories are created inside website-env with permissions ---rws--- (set by the default setting of acl). However, these subdirectories are NOT owned by root, but by the user who ran virtualenv. His user class permissions on those subdirectories are ---, hence virtualenv cannot modify them.

The solution is to allow owners full access to subdirectories, ie. with default:user:rwx in the acl. Security is not compromised, since those files/directories will be owned NOT by root, but by the user who makes them, who should probably have access anyway.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top