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

Kevin openafs@gnosys.biz
Thu, 21 Apr 2005 13:08:56 -0400


Hi List-

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.

In particular, Gentoo uses the directory /var/tmp/portage as a sort-of tmp 
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.

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.

Towards that end, I created such an afs volume, gave it system:anyuser all 
rights and removed my /var/tmp/portage directory and all contents and in its 
place, put a symlink pointing to the new afs volume.

But when I emerge a package with this configuration, I get problems.

The Gentoo Portage system likes to make a tree at this /var/tmp/portage site 
like so (for the links web browser):

poseidon portage # ls -lR links-2.1_pre15/|grep links-2.1_pre15/
links-2.1_pre15/:
links-2.1_pre15/build-info:
links-2.1_pre15/temp:
links-2.1_pre15/work:
links-2.1_pre15/work/links-2.1pre15:
links-2.1_pre15/work/links-2.1pre15/Unicode:
links-2.1_pre15/work/links-2.1pre15/doc:
links-2.1_pre15/work/links-2.1pre15/doc/links_cal:
links-2.1_pre15/work/links-2.1pre15/graphics:
links-2.1_pre15/work/links-2.1pre15/graphics/font:
links-2.1_pre15/work/links-2.1pre15/graphics/font/century_school-bold-roman-serif-vari:
links-2.1_pre15/work/links-2.1pre15/graphics/font/century_school-medium-roman-serif-vari:
links-2.1_pre15/work/links-2.1pre15/graphics/font/courier-medium-roman-serif-mono:
links-2.1_pre15/work/links-2.1pre15/graphics/font/japanese-medium-roman-sans-mono:
links-2.1_pre15/work/links-2.1pre15/graphics/font/symbol-medium-roman-sans-vari:links-2.1_pre15/work/links-2.1pre15/graphics/system_font:
links-2.1_pre15/work/links-2.1pre15/intl:
links-2.1_pre15/work/links-2.1pre15/parser:

Some ownership and mode information on this tree is here:

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.

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?

Thanks for any suggestions.

-- 
Kevin
http://www.gnosys.us

-- 
Kevin
http://www.gnosys.us