Security and set*id() is not my forte, nor do I desire it to be.  :)
So I could use a little assistance...

  How I understand it, mount_portal works by, whenever an access to a
portion of the appropriate namespace occurs, the mount_portal
process forks, and the new child handles the request.

  In pt_file.c, the forked mount_portal process (the one handling
a specific request) does setegid/setgroups/seteuid to presumably
lower its credentials to those of the process accessing the
namespace.  According to my minimal knowledge and the man pages
and source, only root can call setgroups with any success. 
Thus, if a user does an fs mount_portal, _no_ one can access
it:  the user owns the mount_portal process, and its
setgroups() calls will fail.

  Thus, the fs mount type is only useful if the mount is
performed by root.

  Would it make sense to weaken the set*id() calls to the
following:

  If uid (of the mount_portal child) == 0, lower our credentials
    (including setgroups()) to those of the calling process,
    i.e., use the code as it is.
  Else, if uid of the mount_portal child match uid of the calling
    process, and gid of the mount_portal child is contained in the
    calling process' pcr_groups, then simply continue (skip
    seteuid, setgroups, and setegid calls).

  That way, user bgrayson can do a mount_portal and access the
"fs" namespace, but other users can not access the "fs" portal
via bgrayson's mount point.

  So, does that make sense, or would that open up security holes
that are best left closed?

  Thanks in advance.  (By the way, is there a mount_portal guru
in the house?)

  For those of you wondering, once this issue is resolved, I'll
check in the rfilter and wfilter changes discussed on tech-kern
3 weeks ago.  If anyone would like to volunteer to look at the
code before I commit it, please send me mail.

  Brian