[OpenAFS] Creating a tmp volume in afs (for Gentoo /var/tmp/portage)

[Sergio Gelato]

* Kevin [2005-04-21 13:08:56 -0400]:
> Realizing that this might be a questionable security practice, I'd like to 
> learn how to set up an afs volume that would be mounted in the afs tree and 
> that would act as a replacement for a locally mounted /tmp partition where 
> running processes could write stuff willy nilly.

I think it's questionable from the point of view of performance as well.
That said, you could just use an IP-based ACL on it. The sticky bit may
not work as expected, though. More seriously, don't expect cross-directory
hard links to work.

> In particular, Gentoo uses the directory /var/tmp/portage as a sort-of tmp 

You can configure that to be any directory you like. Including /tmp/portage,
and if you use tmpfs for /tmp that could be very similar to AFS with a
memcache. (The contents won't survive across reboots, but for this application
I don't think it matters.)

I think doing ebuilds in anything other than a filesystem with traditional
Unix semantics is asking for trouble.

> directory place in which to unzip and build all of the software associated 
> with its ebuilds, and I'd like to make an afs volume that a 
> symlink /var/tmp/portage could point to.  When emerging large packages like 
> kde or openoffice, this tree gets very bloated and it would be nice to get it 
> out of the locally mounted disks.

Why? Any sane person contemplating a large Gentoo deployment will build
binary packages on one machine (presumably a fast one with adequate memory
and disk space) then distribute those to the rest (perhaps via AFS).

> I'm sure there are many implications that should be seriously considered 
> before making such a thing a permanent feature (such as two gentoo boxes 
> emerging the same package at the same time where each gentoo box has a 
> symlink pointing to this afs volume---which box gets exclusive rights to the 
> subdirectory in that tree associated with the package's build?), but I'd like 
> to at least experiment with the notion.

In my experience, Gentoo doesn't cope all that well with concurrent emerges
even on the same computer.

> poseidon portage # ls -l links-2.1_pre15/
> total 12
> drwxr-xr-x  2 root    root    4096 Apr 21 12:23 build-info
> drwxrws---  2 portage portage 4096 Apr 21 12:24 temp
> drwx------  3 root    root    4096 Apr 21 12:22 work
> 
> poseidon portage # ls -l links-2.1_pre15/work/
> total 4
> drwxrwxrwx  7 root root 4096 Apr 21 12:28 links-2.1pre15
> 
> When I try to emerge links with this arrangement, I get all sorts of 
> permission denied errors when trying to open files for writing below the work 
> subdirectory.  This is true even though I invoked the emerge process as the 
> box's local superuser and with tokens for the afs superuser.

Try disabling the sandbox feature. (FEATURES=userpriv looks promising.
It's documented in the make.conf(5) man page.)

> I suppose that the emerge process drops superuser rights at some point and 
> that's probably the explanation for this, but is there any way that anyone 
> can think of to basically grant any user the right to write in any way 
> (subdirectories within subdirectories and so forth) to this volume?

I haven't studied the internals of ebuild in detail yet, but if my guess that
the sandbox involves a chroot is correct, all the usual problems with accessing
AFS from within a chroot environment apply.

You could of course just create a big file in AFS, mkfs an ext2 filesystem
into it, and loop-mount it onto /var/tmp/portage.