On Fri, Jan 14, 2011 at 9:08 AM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Thu, 13 Jan 2011 14:45:59 -0600 > Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > >> > >> > What exactly do you intend to protect with client-side enforcement? >> >> Jeff, with client side permission checking/enforcment, as I understand, >> we are checking for accesses (read, write, etc.). Is that correct or >> is there more to that? >> > > There's (far) more to it than that. As I said, the server is going to > enforce permissions based on the user in the SMB session. So, if you > enforce permissions on the client, then what you end up with is a > permissions set comprised of the permissions you're enforcing on the > client logically AND'ed with those that the server enforces. > > Even if you were able to present that somehow, there are significant > problems with trying to enforce permissions on the client, particularly > in the face of file and directory creation. Look at it this way: > > Suppose that you get idmapping working and find a way to perfectly map > ACLs to modes on the client. At that point, you'll have file ownership > and mode that reflects the permissions on file. So, the situation at > that point is very similar to the situation where unix extensions are > enabled and the uid/gid are identically mapped on client and server. > > This is a simple configuration to set up, so let me give you a simple > "exercise" in such a configuration: > > Mount up a share using a set of credentials that map to "alice" on > the server. On the client, become user "bob". cd into a world-writeable > directory on the cifs mount and "touch" a file that does not yet exist: > > [bob@client]$ touch bob > touch: cannot touch `bob': Permission denied > [bob@client]$ ls -l bob > -rw-r--r--. 1 alice alice 0 Jan 14 09:31 bob > > ...so what happened here? The file was created, but because the > credentials don't map to "bob", it's owned by "alice". The utimes() call > then failed due to client side permissions enforcement (bob doesn't > have write access) and "touch" returned an error. > > There are similar problems with directory creation (can't create new > entries in a directory that you just created), and with file/directory > removal (can't remove a file or directory that you just created). It's > easy to run afoul of this. > > The lesson here is that inode creates matter, and you can't work around > this fact if you're enforcing permissions on the client. This is horribly > confusing to users. There are many examples over the years of cifs > users complaining about this when unix extensions are enabled. > > There's another problem too...you can only enforce the permissions that > you *have*. Even if you can perfectly map/enforce permissions on the > client, it's easily possible for them to change after you fetch them. > > Even if you were to fetch the ACL prior to every access (which would be > horrible for performance), you still have a race window between > fetching the ACL and enforcing it. > > These problems with permissions are the primary reason why I did the > multiuser mount code. After working on this problem and answering > questions from confused users for a couple of years, I came to the > conclusion that the only sensible fix is to avoid permissions > enforcement on the client altogether. > > But...cifs mounts are single-user by default. People often use the inode > permissions to restrict access to the mount. What we probably ought to > consider doing there is setting the i_mode according to the > file_mode/dir_mode options and enforce them on the client using that. > If unix extensions or cifsacl are enabled, then store the mode in a > separate place in the cifsInodeInfo and present that in the getattr > call. It's still confusing but that makes a heck of a lot more sense than > what we have now. > > In any case, I'm not keen on the idea of adding yet another way to set > the mode on files until we have a sane way of dealing with some of the > existing problems. If you want to first sort out the mess with > permissions and unix extensions, then I might be more interested. > > -- > Jeff Layton <jlayton@xxxxxxxxxx> > Jeff, Thanks. Need to think this over. Wish there were a commands/subcommands like getpathinfo and gethandleinfo with infolevels to determine what functions GetEffectiveRightsFromAcl and AccessCheckByType provide. Perhaps these are Windows APIs providing these type of services and there is a named pipe providing these services. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
