On Fri, Nov 25, 2016, at 01:24 PM, trondd wrote: > On Fri, November 25, 2016 2:01 pm, Dave Cohen wrote: > > I'm new to `chroot`. Trying to make sandbox where I can build and run > > untrusted code without affecting the base system. > > > > Following instructions from > > https://www.ibm.com/developerworks/community/blogs/karsten/entry/openbsd_chroot?lang=en, > > I am at the point where I can `doas chroot /jails/untrusted/` and I have > > root access to my chroot environment. So far, so good. > > ... > > It's an old how-to. There are no etc sets anymore. Did you run sysmerge > in the chroot or otherwise extact the etc tarball out of the base > tarball?
I noticed the missing etc tarball and the older version, but assumed the approach would still work. Hadn't tried sysmerge. > > Also, depending on what you're trying to do in the chroot, maybe look into > leveraging proot from ports. > Ok, that is great to know about! I'm not looking specifically to build ports (right now). Still `proot` seems flexible enough for my purposes, which is to run programs in separate chroots. However `chroot` is not behaving the way I expected it to. Once chrooted, I have environment that comes from the user who called `chroot`, and not the user passed to `chroot -u user`. Below shows what I'm talking about. I'm logged in as "admin", then I `chroot -u user`, then I call `env` and see values consistent with "admin" not "user". Still `whoami` returns "user" as expected. Is this proper behavior from `chroot -u`? And is there a way to be "user" in the chroot, without any trace of "admin" who is the caller of `chroot`? admin@tripper:/home/admin $ whoami admin admin@tripper:/home/admin $ doas chroot -u user /jails/proot/ $ whoami user $ env LOGNAME=admin HOME=/home/admin PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/usr/local/sbin TERM=screen-256color USER=admin I'm using 6.0-release, if that matters.
