[linux-cifs-client] [PATCH 0/3] cifs: some random patches for 2.6.31

[Steve French]

1) I wanted to look at more to make sure how it affected (if at all)
the "homedir" case
(ie we want to override the uid on the mount since the files are owned by the
same user, but we do not need to override the mode)

2) No problem with restricting the default mode.
If we want to restrict it to more than the Samba default, 0744,
which seems intuitive, I would like feedback from some users
on this.  (Samba uses 0744, and that seems a sensible default to me,
and probably is easier to be consistent).

3) No problem will merge very soon

On the mount.cifs patch, I like your change a lot, but haven't looked
to see how hard it would be to add an extra option/keyword etc.
to allow root to specify (e.g. in fstab) that a particular user can mount a
particular directory (directories?) to any server.  Without that, or
something like it, the (many) users I have talked to who don't
necessarily know the server name they need to mount when
the fstab is created/configured are out of luck and have to use
other user space tools like smbclient (or know the root password)
to mount something after boot time into e.g. their home directory.
In the past our documentation told the administrator (root) to
make mount.cifs setuid in order to let users mount
something into a directory they own, and if you think that is
too general (e.g. to put an equivalent keyword like "owner" in fstab)
we have to at least be able to specify this for a particular
directory/user combination narrowly in fstab.   I think at least one other
distros had a specific fstab for smbfs which was handled differently,
but I think it makes more sense to do as you have done and
use the standard fstab.

On Tue, May 26, 2009 at 5:30 AM, Jeff Layton <jlayton at redhat.com> wrote:
> On Mon, 25 May 2009 13:55:31 -0500
> Steve French <smfrench at gmail.com> wrote:
>
>> On Mon, May 25, 2009 at 12:56 PM, simo <idra at samba.org> wrote:
>> > On Mon, 2009-05-25 at 13:28 -0400, Jeff Layton wrote:
>> > I was thinking that maybe we should send locks only when we explicitly
>> > make them mandatory. As we are not respecting them on the client anyway
>> > when they are not.
>>
>> We have to send byte range locks to the server (by default). In particular
>> to handle when multiple clients are locking the same file.  With some
>> help from jra a few years ago, I think the mapping (advisory
>> to mandatory, when mounted to windows) works about as
>> well as we can do, and works for most posix apps.  There are some
>> cases where users have to disable the duplicate lock enforcement
>> on the client or the reverse (ie stop sending (mandotory) locks
>> to the server) and so there are mount options to disable these.
>>
>
> Agreed...
>
> So in a general sense, are there any objections to the first two of
> these patches? I'm assuming that patch #3 is OK, but I'm not clear on
> whether you want to see changes the other two.
>
> Thanks,
> --
> Jeff Layton <jlayton at redhat.com>
>



-- 
Thanks,

Steve