
Show HN: Avenv – A more isolated virtualenv - ihucos
https://github.com/ihucos/avenv
======
shakna
I'd like to say good things, but there are a few big issues first.

It goes to the effort of downloading the sha256 hashes... For a filename. It
never actually confirms a download is accurate with them. (curl --fail is not
enough. You can have connections close nicely, but the file not be transferred
correctly.)

It depends on bchroot for the heavy lifting, which is a beta product still,
though interesting, and your own... And the habit of placing binaries in git
do give me some twinges of concern. It would take more time than I have to
audit bchroot. I have some concerns about binding /tmp and /dev the way you
do... But a bigger concern is the assumption that /bin/bash will be available.
What if it isn't?

It copies _my_ resolv.conf into the chroot blindly, despite the fact that many
network managers may overwrite this file, and that my computer can move
between networks where this may change. It'd be better to at least symlink the
file. Best would be running a network manager.

It assumes x86_64. Reasonable-ish, but not always accurate. A Raspberry Pi is
just as strong a target. Use uname -m. You'll probably hit issues otherwise.

Speaking of which, if you feel the need to grab resolv, you probably want
hosts as well.

avenv-update finds and sorts binaries from a few static locations. It'd be
much better if it could rely on a PATH variable.

\---

As a _first_ chroot manager attempt, it's not awful.

You set the right failure flags for sh, and handle most of the fail conditions
nicely.

... But never trust the internet to hand you blindly what you ask for.

... And never trust the assumptions you've made about what it's running on
will also be accurate.

~~~
ihucos
The whole shell script is really just because it's a protoype (=Initial
commit). If I get good feedback, I'll rewrite this in proper python code. At
least for myself it's already good enough to use it.

The thing that worries me more is the bchroot.c, but since it does not promise
any guarantees on isolation and is not setuid or so there really should'nt be
any security issues.

> I have some concerns about binding /tmp and /dev the way you do...

Can you elaborate what exactly the issues is? I use this quite often.

> But a bigger concern is the assumption that /bin/bash will be available.
> What if it isn't?

Then you'll have to call 'bchroot ./rootfs /bin/ash' instead of just 'bchroot
./rootfs', just like with the regular chroot.

> It copies _my_ resolv.conf into the chroot blindly, [...]

bchroot mounts the hosts resolv.conf over it anyway. This is just a redunancy
for some corner case I have (whole programming environment already inside an
namespaced chroot)

~~~
shakna
> If I get good feedback, I'll rewrite this in proper python code.

I don't mind it being a shell script. So is arch-chroot, which is an amazing
little tool.

> > I have some concerns about binding /tmp and /dev the way you do...

> Can you elaborate what exactly the issues is? I use this quite often.

It's a container escape. The chroot shouldn't be able to access the hosts tmp
files. Creating a tmpfs and using that is a safer method. If you can read and
write the hosts tmpfs, then you can impact the behaviour of the host.

The cheap way would be making a directory in /var/shm and symlinking to it.

The better way is creating a ramfs and mounting it.

For /dev it's just because it has to be a proper bind, and I haven't looked
deeply enough to check that happens.

> bchroot mounts the hosts resolv.conf over it anyway.

I'll still wait til you fix that symlink problem you've noted in the source -
my resolv is definitely a symlink.

> Then you'll have to call 'bchroot ./rootfs /bin/ash' instead of just
> 'bchroot ./rootfs', just like with the regular chroot.

/bin/sh is generally guaranteed to exist (more often than /bin/bash). That's
all. (Though technically the path /bin/sh isn't guaranteed by POSIX. You're
supposed to use /etc/passwd to find the shell.)

> At least for myself it's already good enough to use it.

The goal of all software, if it works for you, fantastic.

~~~
ihucos
> > > I have some concerns about binding /tmp and /dev the way you do...

> > Can you elaborate what exactly the issues is? I use this quite often.

> It's a container escape. The chroot shouldn't be able to access the hosts
> tmp files. Creating a tmpfs and using that is a safer method. If you can
> read and write the hosts tmpfs, then you can impact the behaviour of the
> host.

ok ja, I know, I am also mounting /home. There are no guarantees that there is
any security gain by using this and security is not the goal of this software.

> For /dev it's just because it has to be a proper bind, and I haven't looked
> deeply enough to check that happens.

I am using `mount("/dev", "./rootfs/dev", "none", MS_MGC_VAL|MS_BIND|MS_REC,
NULL)` so a recursive bind so we also get stuff like "/dev/pts". I am using
this regularly and it works perfect for me, let me know if you know of any
specific problems with this!

------
mdaniel
Please don't put binary artifacts in git; GitHub offers "releases," which are
essentially download buckets attached to git tags, from which one can download
tars. To the best of my knowledge they're still curl-into-bash-able (or I
guess into tar, in your case)

------
pietroglyph
It uses xbps!

    
    
        $ venv/bin/xbps-install -Sy libreoffice xorg-fonts # you can imagine that as kind of like a chrooted void linux
    

I wonder how easy this is to do with other package managers? Is this a feature
specific to xbps?

~~~
ihucos
This also works with others package managers/distributions. Only with apt/apt-
get you need some extra configuration "APT::Sandbox::User=root"

I was thinking about using Ubuntu, but in the end took void linux because it's
the smallest glibc based distribution I could found. Python wheels don't work
on musl based distributions

------
sedeki
Seems a bit scary to install it like that

~~~
ironmagma
Seriously. At least add in an MD5 hash, jeez.

------
fiatjaf
I'll not use this, because I've had enough of Python and will do my best to
not start any new Python programs (also I don't know how is this better than
virtualenv), but the README is truly awesome.

------
ihucos
To my haters: It's clearly a prototype. 60 lines of shell script will always
have their own issues. What I'd love to hear is thoughts on the general
approach! Is this cool enough to do proper?

------
cipherzero
Is this a serious project?

> Linux only support

>

> Tell your employer to stop using Macintosh

... because that doesn’t seem like a sign of a serious project to me...

~~~
dang
Show HNs don't have to be serious projects. Please don't post shallow
dismissals.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

[https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

