0

I am an user with no superuser rights. I normally build and install the tools I need within my /home/<user> directory, and then create aliases to be able to run my programs. However, this is creating a bit of a mess.

What would be a saner way of creating a filesystem hierarchy within /home/<user> so that I can have something resembling better a Linux Filesystem Hierarchy? Something similar to a Python virtualenv, so I can install libraries I need without needing superuser support?

Gilles 'SO- stop being evil'
  • 829,060
dmvianna
  • 407
  • 2
    I recommend GNU stow (which I wrote about in http://unix.stackexchange.com/questions/16375/keeping-track-of-programs; >>TODO update that and mention stow on http://unix.stackexchange.com/questions/42567/how-to-install-program-locally-without-sudo-privileges). – Gilles 'SO- stop being evil' Dec 02 '14 at 23:38
  • @Gilles, sounds like THE answer! Post an answer and I'll choose it once I can verify it works. Thanks! – dmvianna Dec 03 '14 at 00:14

1 Answers1

1

You can use - if you can get the initial right to do so granted to you - the linux kernel's User namespaces. In a user namespace a user can be apportioned a piece of a disk and run a full-fledged container within as a super-user without otherwise affecting the parent environment. You will need a 3.8 or later kernel, some linux-savvy, and the initial setup before it will work.

mikeserv
  • 58,310
  • I didn't know that. It won't work in my current situation, unfortunately. We're running very stable. ;7) – dmvianna Dec 01 '14 at 23:32
  • @dmvianna - that's a shame. That said, 3.8 is only the point at which the namespaces as a whole were considered complete - the user namespace was the last. The mount namespaces, on the other hand, were introduced in 2.5 or 2.6. A mount namespace allows a process to have its own private mount tree. Given your own shell with its own private mount tree, you could privately mount home with other rights than other processes have - and do a permanent chroot like scenario in that way. And never underestimate the power of mount --bind given a little ingenuity and a lot of /etc/fstab. – mikeserv Dec 01 '14 at 23:35
  • This is a good idea. However, I do not want to shadow the current root system, just overlay on it. Mounting over /usr/local would be nice, for example, except that I don't have mounting rights. Same obviously goes to chroot. :P – dmvianna Dec 01 '14 at 23:50
  • @dmvianna - yes - that is a hangup. You can overlay it with shared mounts - that is a deeply complex and powerful tool at a super-user's disposal. Anything useful you do along these lines - as I noted in the answer - is going to require initial setup and permission of a superuse. – mikeserv Dec 01 '14 at 23:55
  • Maybe I didn't make it clear in my question, but I would be happy to just have my personal /home/<user>/usr/local, etc., and it working seamlessly for me. I am able to do just that, except that the hierarchy looks more like an /opt (it follows the program, not the Unix standard), and interoperability between programs fails. That is, I can only have programs that do not rely on shared libraries. Are you telling me it cannot be done or are you telling me you don't know how to do just that? – dmvianna Dec 02 '14 at 00:09
  • @dmvianna - Well, I suppose it might be done if you simply compiled everything yourself with the right path prefixes - but precompiled binaries will almost always point to the defaults. The only to way to handle that is a symlink or a mount. You cannot - and shouldn't want to - install symlinks into {/usr,}/bin:/lib without root priveleges, but you might shadow a mount tree with a somewhat peculiar /etc/fstab as a non-root user. – mikeserv Dec 02 '14 at 00:13
  • Yep, I do compile everything and add prefixes. That's what gives me the /opt like hierarchy (which works to a point, but is not perfect). I might try the /etc/fstab route. However, it doesn't strike me as the cleanest thing, and will involve much institutional pain. :P – dmvianna Dec 02 '14 at 00:23
  • 1
    @dmvianna - agreed - it is not ideal. A container would be ideal. There are other - less simply implemented - containerization options available to you. The user namespace was my first suggestion because it is a builtin feature to the linux kernel - though that may have its own problems as some distros do not enable that compile-time option. Given that kernel feature it is probably the most simple way to go, next best - as far as I know - is custom shared mount tree. But, as I said, painful or not, anything useful along these lines will require initial institutional support. Sorry. – mikeserv Dec 02 '14 at 00:28
  • 1
    This looks like the answer to me: shared subtrees – dmvianna Dec 02 '14 at 04:08
  • 1
    @dmvianna - yup, that's the one - and precisely the doc I had in mind when I was referring to next best. It can, unfortunately though, get very complicated. Most important, as I've found, you must mount --make-rundbindable the root of the share when you share it. Otherwise you wind up recursively mounting it over itself when you do - it can get pretty messy that way. Like, mounting / in /tmp/root will get /tmp/root/tmp/root/tmp/root.... and so on. If /tmp/root is unbindable though, it cuts that problem off at the head. – mikeserv Dec 02 '14 at 21:42