Re: [LSF/MM TOPIC] Unified keys for NFS, CIFS and AFS for security data

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Feb 5, 2011 at 7:03 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote:
> On Fri, 21 Jan 2011 15:34:27 +0000
> David Howells <dhowells@xxxxxxxxxx> wrote:
>
>>
>> I'd like to propose a discussion topic for the LSF: how best to implement a
>> common key type for use by NFS, CIFS and AFS such that, say, a kerberos key
>> can be encapsulated within one and then be pulled out by various filesystems.
>>
>> Furthermore, it would be necessary to allow the request_key() upcall mechanism
>> to perform GSSAPI queries.
>>
>
> I would be interested in discussing this as well. Currently CIFS
> "punts" to some degree and offloads almost all of the SPNEGO blob
> construction to userspace. So, for CIFS this would involve moving more
> of this code into the kernel. I think that's a good thing since it will
> make it easier to do mutual-authentication, etc...

Yes. I also agree, in part because the more the upcall has to go
to userspace the more likely a reconnect (network connection
drop) can cause problems when memory available to userspace
is constrained by a large amount of cached data on the network mount.


> This would make it more plausible to store krb5 credcaches in the
> kernel keyring too. Modern MIT krb5 libs can do this today (I think),

yes

> The difficulty here is that request_key() is "stateless", so we need to
> think about how to manage GSSAPI contexts across multiple upcalls...or
> plan to implement large swaths of the GSSAPI in-kernel.

> It might also be helpful to couple this with some consolidation and
> cleanup of the ASN.1 parsing code in the kernel. There are at least 3
> separate implementations in the kernel today (one in cifs, one in
> sunrpc, and one in iptables).

This is harder, but would also simplify future work as well
(such as SMB2, which will require this more often in
sessionsetup than cifs)



-- 
Thanks,

Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux