On Mon, 29 Sep 2008, David P. Quigley wrote:
> * New security flavor (auth_seclabel) to transport process label to
> server. This is a derivative of auth_unix so it does not support
> kerberos which has its own issues that need to be dealt with.
This is a problem, as discussed last year:
http://linux-nfs.org/pipermail/labeled-nfs/2007-November/000110.html
We can't require the use of a new auth flavor which is incompatible with
auth_gss.
- James
--
James Morris
<[email protected]>
James Morris wrote:
> On Mon, 29 Sep 2008, David P. Quigley wrote:
>
>> * New security flavor (auth_seclabel) to transport process label to
>> server. This is a derivative of auth_unix so it does not support
>> kerberos which has its own issues that need to be dealt with.
>
> This is a problem, as discussed last year:
>
> http://linux-nfs.org/pipermail/labeled-nfs/2007-November/000110.html
>
> We can't require the use of a new auth flavor which is incompatible with
> auth_gss.
auth_seclabel demonstrates the flavor independent changes required for
any RPC layer process label transport. A GSS solution is currently
under discussion.
On Mon, 2008-10-13 at 22:15 -0400, Matthew N. Dodd wrote:
> James Morris wrote:
> > On Mon, 29 Sep 2008, David P. Quigley wrote:
> >
> >> * New security flavor (auth_seclabel) to transport process label to
> >> server. This is a derivative of auth_unix so it does not support
> >> kerberos which has its own issues that need to be dealt with.
> >
> > This is a problem, as discussed last year:
> >
> > http://linux-nfs.org/pipermail/labeled-nfs/2007-November/000110.html
> >
> > We can't require the use of a new auth flavor which is incompatible with
> > auth_gss.
>
> auth_seclabel demonstrates the flavor independent changes required for
> any RPC layer process label transport. A GSS solution is currently
> under discussion.
Right, but I'm not particularly interested in merging "demonstration"
code that might end up requiring permanent support. I'd very much like
to see all of this get further through the IETF process before we talk
about merging into mainline.
Cheers
Trond
On Tue, 2008-10-14 at 09:20 -0400, Trond Myklebust wrote:
> On Mon, 2008-10-13 at 22:15 -0400, Matthew N. Dodd wrote:
> > James Morris wrote:
> > > On Mon, 29 Sep 2008, David P. Quigley wrote:
> > >
> > >> * New security flavor (auth_seclabel) to transport process label to
> > >> server. This is a derivative of auth_unix so it does not support
> > >> kerberos which has its own issues that need to be dealt with.
> > >
> > > This is a problem, as discussed last year:
> > >
> > > http://linux-nfs.org/pipermail/labeled-nfs/2007-November/000110.html
> > >
> > > We can't require the use of a new auth flavor which is incompatible with
> > > auth_gss.
> >
> > auth_seclabel demonstrates the flavor independent changes required for
> > any RPC layer process label transport. A GSS solution is currently
> > under discussion.
>
> Right, but I'm not particularly interested in merging "demonstration"
> code that might end up requiring permanent support. I'd very much like
> to see all of this get further through the IETF process before we talk
> about merging into mainline.
>
> Cheers
> Trond
Hello,
Nico seems to have come up with a reasonable solution for this
problem we just need to sit down and draw up a document for it.
Apparently he already created a mechanism in rpcsec_gss for allowing you
to bind the rpc session to more than just the normal credentials. Once
we finalize this and get it into a draft we will work on implementing it
in the rpcsec_gss auth flavor.
Dave