* 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. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info