[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