Henry B. Hotz wrote:
At this point we're looking for volunteers, not more wishes, but
here's a wish:
Instead of always going up the tree visiting all parents, have some
way to "stop" so you can securely implement PAG semantics. I don't
think I'd use it often, but I like the idea of being able to set up
an "admin" window and a "secure sandbox" window with more/less
privileges than my default login session.
I would think the AFS folks would be interested in seeing the
Kerberos ticket cache scope match the scope of PAG's as well as
having a PAG implementation that wasn't so dependent on OS-specific
hackery. I'm not sure this is easier than what they do now, but if
it gets AFS and Kerberos on the same page, that's a good thing.
You can simply use mmap'd files to accomplish the functionality that Michael
proposed. Unix mode bits on the file will determine which uids can open the
file. Children of a given process can access it through descriptor inheritance
from a process that already has it open/mapped. A process creating a cache
would just have to export an environment variable giving the cache name and
number of the descriptor in use. (Of course, any child process that closes
descriptors or zaps this environment variable would prevent further
propagation.) e.g. KRB5MEMCC="3000,/tmp/hyc1234"
On Aug 22, 2007, at 10:21 AM, Michael B Allen wrote:
Hi Ken,
I think that the ccache plugin idea is a worthwhile project. Yes, I
think it would solve Alf's original issue. But by itself it would not
solve the shared storage or access control issues (access control
being
what I am really interested in).
The only way to ensure that the ccache is truly protected is with a
kernel extension. I think I would rather invest time into a solid long
term solution and I think a secure shared storage kernel extensions
project would be a step in the right direction.
The extension could be quite simple. The caller could open a file that
and do an ioctl something roughly like:
int fd = open("/dev/sss0", flags)
ioctl(fd, req, "krb5cc[uid=1234,ppid=5678]")
FILE *ccachefp = fdopen(fd, mode)
So the kernel extension could be a simple device file implementation
(this should handle all of the *nix systems). The ioctl data
"krb5cc[uid=1234,ppid=5678]" indicates the name of the storage and
some access control parameters. If the storage is created vs opened
the access control parameters are set. The uid indicates that the
named
ccache is specific to processes with that uid. The ppid indicates that
only processes with that pid or a descendant of that pid (i.e. the
check
would simply walk up the parent pids of the current process until it
matched the supplied ppid) should have access to the storage.
Now if there's some young buck out there looking for an excuse to
experiment with kernel extensions, here's your chance for glory!
Mike
------------------------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
