Solaris ssh pam_krb

[Jeffrey Hutzelman]

On Friday, March 31, 2006 05:24:04 PM -0600 Nicolas Williams 
<Nicolas.Williams at sun.com> wrote:

> On Fri, Mar 31, 2006 at 06:17:53PM -0500, Jeffrey Hutzelman wrote:
>> On Friday, March 31, 2006 04:20:48 PM -0600 Nicolas Williams
>> <Nicolas.Williams at sun.com> wrote:
>> > What other kernel-land applications can you think of or imagine that
>> > fundamentally needs direct multi-application PAG support in the kernel
>> > and can't upcall?
>>
>> - Encrypted (local) filesystems
>
> Orthogonal to PAGs.  The kernel needs to know keys for encrypting
> objects/filesystems, but access controls are as normal (ACLs, mode bits).
>
> We're planning on per-filesystem (think ZFS) keys, too, so there's no
> per-"session" keys to worry about.

I was thinking in terms of different users' files being encrypted with 
different keys, which would require the kernel to track keys on 
approximately a per-PAG basis.


>> - Kernel-mode ticket caches
>
> Circular logic.

No, it's not.  We already established that ticket caches are separate from 
PAG management.  If you want kernel-mode ticket caches (and some of us do), 
then you need kernel-mode access to PAG->appid mappings.


>> Maybe PAG-based authorization for things like X server or ssh agent
>> connections.  In reality, I bet those can be handled in user mode,
>> though  an application like that would require some trusted entity for
>> allocating  ID's which are unique across the system.
>
> Authorization by PAG requires making changes to lots of things in the
> kernel (e.g., two procs w/ equal cred_t's but for different PAGs should
> not be allowed to trace each other w/o special privilege).

Well, yes, and in the long run, you'd want that even if there were no 
kernel-mode users of PAG's.


But I considered the filesystem-driver applications critical.  An upcall 
for every file access is just not going to be acceptable performance-wise.




Really, I think the introduction of a new process to keep track of 
PAG->appid mappings is just silly.  The number of PAG application types in 
the system is likely to be quite small, and the mappings themselves are 
small as well.  Why not just store them in the PAG structure and be done 
with it?

-- Jeff