modifying pam_namespace

[Jan Kasprzak]

	Hello,

I want to do the following:

- I have a server where I want people to have their own (development)
copy of some filesystem subtree. However, the application in question
has many hardcoded paths, so this tree can only be located in a fixed
directory. I thought it would be nice to use pam_namespace.so
to set up a private bind mount for each user, mounting /myapp
to $HOME/myapp.

However, pam_namespace has a problem:
the <prefix> parameter is, well, prefix. I would prefer each developer
to have his own ~/myapp (i.e. a publicly accessible static location;
from time to time we want to show one developer's tree to other
people).

	I propose that the namespace.conf syntax should be changed
- the <prefix> parameter should be changed to contain the whole
directory name (not only a prefix), and another variables (besides
$USER and $HOME) should be implemented (such as $CONTEXT, $CONTEXT_MD5
and $LEVEL). This way user will be able to specify the security context
to be added even somewhere else than the end of the directory name, etc.

	Maybe for backward compatibility we can add it as another
polyinstantiation method - say - "static", indicating that the directory
name should be constructed from the second parameter as a whole, not as
a prefix.

So the namespace.conf line for my case would read:

/myapp	$HOME/myapp	static	root

Another example, the following two pairs of lines would be equivalent
with the new "static" method:

/tmp       /tmp-inst/            level    root
/tmp       /tmp-inst/$LEVEL      static   root

/var/tmp   /var/tmp-inst/        user     root
/var/tmp   /var/tmp-inst/$USER   static   root

	Would you be OK with such change to pam_namespace?
Should I try to write it and send a patch?

	Thanks,

-Yenya

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/    Journal: http://www.fi.muni.cz/~kas/blog/ |
>     So at least in some cases, I think we should "default to stupid,     <
>     but give users rope".                           --Linus Torvalds     <