Ken MacKenzie <ken@mack-z.com> writes:
> Is there a recommended best practice when setting up an environment with
> python
> virtualenv with regards to wxallowed.
AFAIK nothing official.
>
> My typical workflow is under my home directory I have a
> dev/language/project/.venv type structure. I guess the simple solution is to
> mount /home as wxallowed in /etc/fstab, but is that truly the preferred way.
> Seems to make a new attack surface for anything in home.
>
Turning off any default mitigations is probably the opposite of "preferred".
> The other option I am thinking is to create a dev-username location in
> /usr/local somewhere and then ln -s that into my home structure accordingly.
>
> Since I am new to OpenBSD I figured I would ask first and did not find much
> on
> this topic other than third parties that seem to want to casually just add
> home
> to wxallowed.
>
I've been too lazy to dig into and "fix" this in the py{2,3}-virtualenv
port. The main issue is it copies the binary for the target python
executable and doesn't symlink it. It's really not a bug and more an
adaptation issue so I've not been inclined.
However, symbolic links to /usr/local/bin/python work fine if they're
located on partitions that aren't mounted wxallowed. I'd imagine if
virtualenv created a symlink things would "just work."
So what I do, instead of teaching virtualenv to symlink instead of copy,
is just confine my virtualenvs to /usr/local/venv (owned by root:wsrc).
I then just activate via the usual means of the activate script:
kogelvis$ . /usr/local/venv/my-project/bin/activate
Typically, on other systems, I'd locate it in ~/.venv but for my
personal machine it's not an issue.
I do set an environment variable:
WORKON_HOME=/usr/local/venv
in .profile so I can configure tools like emacs major modes to point to
where I want them to create/find virtual environments.
> Thanks in advance for any guidance,
>
> Ken
No comments:
Post a Comment