[linux-cifs-client] [RFC PATCH] CIFS posix acl permission checking

[Jeff Layton]

On Fri, 12 Mar 2010 13:23:01 +0100
Volker Lendecke <Volker.Lendecke at SerNet.DE> wrote:

> On Fri, Mar 12, 2010 at 07:18:32AM -0500, Jeff Layton wrote:
> > > But what's the alternative? Let NFS go and do that piece
> > > better forever? :-)
> > > 
> > > Volker
> > 
> > Establish sessions as needed, based on a user's own credentials and
> > have the kernel use that session/tcon combinaton instead of those
> > established at mount time. My goal is to have a prototype of this to
> > present at SambaXP, but I may have an initial set of patches in the
> > next few weeks.
> 
> Ok, then we rule out batch machines where there are no user
> credentials. NFS does this fine. I know this is REALLY ugly,
> but I have customers who need this. If you have a good
> solution for that problem, I would really be happy to hear
> this. Something like constrained delegation in Kerberos to
> me sounds pretty much like the exact same hack in a
> different place.
> 

I'm not familiar with constrained delegation, so I'll have to read up
on that before I can comment on it. 

If you want to do something like this, why bother with a privileged
session at all? Why not just add a new authentication method for CIFS
(under GSSAPI maybe?) that works like AUTH_SYS but without the
arbitrary group list limit? The server could be configured then to
permit this auth scheme only for certain clients.

...or once I (or someone else) get multisession mounts working, you
could generate a krb5 keytab per uid, put them in a well-defined
location and then teach cifs.upcall how to find them. That seems like a
reasonable idea that doesn't involve extending the protocol. For that
matter, they could do something similar with NFS (teach rpc.gssd how to
find user keytabs).

Now, all that said -- like Jeremy I wouldn't have a specific objection
to adding what you suggest, but for one thing:

CIFS is already a god-awful mess when it comes to handling permissions.
There are a ton of options that affect how it deals with permissions.
Many of them conflict and the effect of their union is poorly
understood. It's a maintenance and support *nightmare*. Adding this
means adding more options and yet another set of behavior, and that
worries me.

-- 
Jeff Layton <jlayton at samba.org>