On Jun 8, 2007, at 09:33, Todd M. Lewis wrote:
Zach wrote:
I was talking to our sys admin. about allowing us users to run cgi
programs from our afs accounts (served from $HOME/www which has
"system:anyuser rl") and asked if the web server could do this and
was
told first that the CMU AFS team was working on a way to make CGI
principles for andrew (AFS realm) users so we can support them on
contrib (AFS realm) and then later told they ran into a problem with
permissions but had to work on the code a bit more. This was 8 months
ago and still waiting for this to be finished. [...]
You might want to look at https://lists.openafs.org/pipermail/
openafs-info/2002-May/004471.html to see how we run our GCI scripts
out of AFS. It lacks some of the elegance of http://www.umbc.edu/
oit/iss/syscore/wiki/Mod_waklog, but it has served us very well.
Whereas Mod_waklog uses a real Apache module, we use a ScriptAlias
to an external program to fix up the runtime environment for user's
scripts.
What we do for our "userpages" cgis, is we run apache under one
kerberos principal (which is tied to a UID, not a PAG), and run all
of our CGIs & PHPs under another via a slightly modified suexec which
jumps to a UID that has another set of tokens tied to it.
Benefits:
People serving out static content can't hurt one another.
Cons:
All of the people serving dynamic content can step on each other, or
at least the directories that they've made writable by the cgi
principal.
As the environment exists primarily for instructional purposes and
not production content service, this has generally worked out... The
mod_waklog stuff would be nice to use there, but there'd be the
management of a WHOLE lot of krb principals involved...
-rob
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
