From mboxrd@z Thu Jan 1 00:00:00 1970 From: simo Subject: Re: [linux-cifs-client] review 5, was Re: projected date for mount.cifs to support DFS junction points Date: Sun, 16 Mar 2008 23:14:55 -0400 Message-ID: <1205723695.9351.45.camel@localhost.localdomain> References: <1199988975.7483.3.camel@gn2.draper.com> <20080111090749.GA14910@infradead.org> <524f69650801110805y56cdbe4nf7587e396b70f32c@mail.gmail.com> <20080113202144.GB24573@infradead.org> <47B5BFCF.60304@mail.ru> <20080215170552.GA27584@infradead.org> <524f69650802151302h4e631a74pe382ca932cc85c7@mail.gmail.com> <20080215221158.GA15021@infradead.org> <524f69650802251225m1ce0b31dj9b5f7fe6314272ef@mail.gmail.com> <20080308184345.GB1461@infradead.org> <524f69650803102034v59e70442w35d737b4872ce5c4@mail.gmail.com> <20080311083953.08ef093a@tleilax.poochiereds.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Steve French , linux-fsdevel , linux-cifs-client@lists.samba.org To: Jeff Layton Return-path: Received: from mail.samba.org ([66.70.73.150]:34628 "EHLO lists.samba.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753051AbYCQDTI (ORCPT ); Sun, 16 Mar 2008 23:19:08 -0400 In-Reply-To: <20080311083953.08ef093a@tleilax.poochiereds.net> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue, 2008-03-11 at 08:39 -0400, Jeff Layton wrote: > On Mon, 10 Mar 2008 22:34:35 -0500 > "Steve French" wrote: > > > On Sat, Mar 8, 2008 at 1:43 PM, Christoph Hellwig wrote: > > > On Mon, Feb 25, 2008 at 02:25:50PM -0600, Steve French wrote: > > > > On Fri, Feb 15, 2008 at 4:11 PM, Christoph Hellwig wrote: > > > Okay, now that we have the basic consolidation in can I get you to > > > review force_uid_gid paramter to cifs_unix_info_to_inode? It seems > > > more than fishy to me to ignore the CIFS_MOUNT_OVERR_{UID,GID} options > > > in cifs_get_inode_info_unix but not in posix_fill_in_inode. This > > > seems more like a missed propagation of changes for a newly added > > > feature to me. If not it should at least get some documentation. > > > > Jeff Layton and I have been discussing the issue of which uid to use > > to fill in the inode->i_uid and I am leaning toward changing the > > default behavior (for the mount to Windows server case) and adding > > another mount parm to allow users to get the older behavior if they > > want. > > > > Unfortunately there are many cases (and the uid/gid owner fields of > > inodes can get filled in potentially in various places > > mkdir/create/mknod and lookup and readdir and of course setattr). The > > mount could be to: > > > > 1) server which support returning uid/gid owner fields for an inode > > (e.g. Samba) on QueryPathInfo > > 2) servers which would support returning a uid, but for which the uids > > on the server don't match the client > > 3) servers like Windows which don't support returning the inodes uid > > > > and for the latter we also have the case of files/directories for > > which the user has chowned it so we know what uid the app thinks it > > should be (or newly created files/directories) > > > > Some of this is documented, and I have started a table which needs to > > be added to the CIFS User's guide - but the case I am most worried > > about at the moment is the behavior when the server would support the > > Unix extensions - but the user has overridden the uid or gid > > (specified on mount, perhaps because the server and client's uids > > differ). For this case should we always use the default uid - or > > should an app be allowed to do a chmod and should we honor the uid/gid > > passed in on the mkdir/create/mknod (as we do for the equivalent > > windows case). > > > > Here's what I'd like to see... > > The best option here is to have a new upcall that does idmapping to map > windows RIDs to unix UIDs. It wouldn't be too hard to do and I have it > on my to-do list, but it's pretty far down and it'll be a while before > I can get started on it. Even with that though, we'll need sensible > defaults for when the upcall doesn't work for some reason. > > In the meantime we have some pretty messy inconsistencies, particularly > when POSIX extensions aren't supported. CIFS sets the in-memory inode's > mode to be consistent with the mkdir/open call, but the ownership is > set to whatever the default uid/gid is for the mount. This makes some > apps work (at least for a little while), but causes other problems. For > instance, someone can create a directory with a restrictive mode but > then can't actually write to it because they don't own it. > > This also seems scary to me from a security standpoint. We're basically > allowing someone to create a file with an arbitrary mode that is owned > by a different user. That user is generally root by default. > > We have 2 separate but related pieces of info to deal with: > > 1) uid/gid: for this I'd like to see an idmapping upcall. When that > info isn't available (daemon is down or no mapping exists), then we'd > fall back to using the "default" uid/gid for the mount. This should be > the behavior regardless of whether we have unix extensions enabled or > not. Right now, we trust that when unix extensions are enabled that we > have unix uid/gid mapped to the same things on all machines. This isn't > necessarily the case. > > 2) mode: for this we have 3 cases. When cifsacl is specified, we'd > use the mode obtained via them. If not, then when unix extensions are > supported, we should use the mode obtained via them. Otherwise, the mode > should be governed by the file_mode/dir_mode of the share. > > At the same time, we should also consider tightening up the default > file_mode/dir_mode. Right now it's 02767 (I think). We should change > that to be 0700, and allow admins to loosen it if they wish. > > The current approach of allowing users to have different info in > in-memory inodes vs. what's recorded on the server seems very > problematic to me. This is something that leads to non-deterministic > behavior and that's worse than just breaking some apps outright. > > Just my 2 lumps of copper and nickel... Jeff, I second this entirely, also as I asked before I'd like to be able to pass SIDs even when Unix Extensions are in use, and not pass UIDs. Passing SIDs would allow us to do a double mapping (on client and on server) that will free us from the need to have the same IDs on all machines. Simo. -- Simo Sorce Samba Team GPL Compliance Officer Senior Software Engineer at Red Hat Inc.