Re: cifs multiuser sends wrong uid:gid [solved]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 04/12/2013 11:42 PM, Jeff Layton wrote:
On Fri, 12 Apr 2013 12:52:32 +0200
steve <steve@xxxxxxxxxxxx> wrote:

On 12/04/13 12:27, Jeff Layton wrote:
On Fri, 12 Apr 2013 11:20:15 +0200
steve <steve@xxxxxxxxxxxx> wrote:

Hi
samba 4.0.5
openSUSE 12.3 cifs-utils-5.9

I have a share:
[users]
path = /home/users
read only = No

I mount it as root:
h16:/tmp # kinit Administrator
Password for Administrator@xxxxxxxx:

hh16:/tmp # klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrator@xxxxxxxx

Valid starting Expires Service principal
04/12/13 11:06:37 04/12/13 21:06:37 krbtgt/HH3.SITE@xxxxxxxx
renew until 04/13/13 11:06:30

hh16:/tmp # mount.cifs //hh16.hh3.site/users /mnt --verbose
-osec=krb5,multiuser
mount.cifs kernel mount options:
ip=192.168.1.16,unc=\\hh16.hh3.site\users,sec=krb5,multiuser,user=steve,pass=********

.
2013-04-12T11:05:49.678122+02:00 hh16 cifs.upcall: key description:
cifs.spnego;0;0;3f000000;ver=0x2;host=hh16.hh3.site;ip4=192.168.1.16;sec=krb5;uid=0x0;creduid=0x0;user=steve;pid=0xaa9
2013-04-12T11:05:49.678807+02:00 hh16 cifs.upcall: ver=2
2013-04-12T11:05:49.678950+02:00 hh16 cifs.upcall: host=hh16.hh3.site
2013-04-12T11:05:49.681949+02:00 hh16 cifs.upcall: ip=192.168.1.16
2013-04-12T11:05:49.681974+02:00 hh16 cifs.upcall: sec=1
2013-04-12T11:05:49.681981+02:00 hh16 cifs.upcall: uid=0
2013-04-12T11:05:49.681986+02:00 hh16 cifs.upcall: creduid=0
2013-04-12T11:05:49.681991+02:00 hh16 cifs.upcall: user=steve
2013-04-12T11:05:49.682443+02:00 hh16 cifs.upcall: pid=2729
2013-04-12T11:05:49.683046+02:00 hh16 cifs.upcall: find_krb5_cc: scandir
error on directory '/run/user/0': No such file or directory
2013-04-12T11:05:49.683488+02:00 hh16 cifs.upcall: find_krb5_cc:
considering /tmp/krb5cc_1000
2013-04-12T11:05:49.683902+02:00 hh16 cifs.upcall: find_krb5_cc:
/tmp/krb5cc_1000 is owned by 1000, not 0
2013-04-12T11:05:49.684385+02:00 hh16 cifs.upcall: find_krb5_cc:
considering /tmp/krb5cc_3000034
2013-04-12T11:05:49.684779+02:00 hh16 cifs.upcall: find_krb5_cc:
/tmp/krb5cc_3000034 is owned by 3000034, not 0
2013-04-12T11:05:49.685567+02:00 hh16 cifs.upcall: find_krb5_cc:
considering /tmp/krb5cc_3000032
2013-04-12T11:05:49.686041+02:00 hh16 cifs.upcall: find_krb5_cc:
/tmp/krb5cc_3000032 is owned by 3000032, not 0
2013-04-12T11:05:49.686352+02:00 hh16 cifs.upcall: find_krb5_cc:
considering /tmp/krb5cc_0
2013-04-12T11:05:49.686638+02:00 hh16 cifs.upcall: find_krb5_cc:
FILE:/tmp/krb5cc_0 is valid ccache
2013-04-12T11:05:49.686919+02:00 hh16 cifs.upcall: handle_krb5_mech:
getting service ticket for hh16.hh3.site
2013-04-12T11:05:49.687248+02:00 hh16 cifs.upcall: handle_krb5_mech:
obtained service ticket
2013-04-12T11:05:49.687523+02:00 hh16 cifs.upcall: Exit status 0


hh16:/tmp # su steve2
steve2@hh16:/tmp> kinit steve2
Password for steve2@xxxxxxxx:
steve2@hh16:/tmp> cd /mnt/steve2
steve2@hh16:/mnt/steve2> touch j
touch: cannot touch ‘j’: Permission denied
2
2013-04-12T11:10:48.599379+02:00 hh16 cifs.upcall: key description:
cifs.spnego;3000034;20513;3f000000;ver=0x2;host=hh16.hh3.site;ip4=192.168.1.16;sec=krb5;uid=0x2dc6e2;creduid=0x2dc6e2;pid=0xb5a
2013-04-12T11:10:48.599412+02:00 hh16 cifs.upcall: ver=2
2013-04-12T11:10:48.601816+02:00 hh16 cifs.upcall: host=hh16.hh3.site
2013-04-12T11:10:48.601840+02:00 hh16 cifs.upcall: ip=192.168.1.16
2013-04-12T11:10:48.601847+02:00 hh16 cifs.upcall: sec=1
2013-04-12T11:10:48.601852+02:00 hh16 cifs.upcall: uid=3000034
2013-04-12T11:10:48.601857+02:00 hh16 cifs.upcall: creduid=3000034
2013-04-12T11:10:48.602956+02:00 hh16 cifs.upcall: pid=2906
2013-04-12T11:10:48.602978+02:00 hh16 cifs.upcall: find_krb5_cc: scandir
error on directory '/run/user/3000034': No such file or directory
2013-04-12T11:10:48.603432+02:00 hh16 cifs.upcall: find_krb5_cc:
considering /tmp/krb5cc_1000
2013-04-12T11:10:48.604677+02:00 hh16 cifs.upcall: find_krb5_cc:
/tmp/krb5cc_1000 is owned by 1000, not 3000034
2013-04-12T11:10:48.605262+02:00 hh16 cifs.upcall: find_krb5_cc:
considering /tmp/krb5cc_3000034
2013-04-12T11:10:48.605779+02:00 hh16 cifs.upcall: find_krb5_cc:
FILE:/tmp/krb5cc_3000034 is valid ccache
2013-04-12T11:10:48.607568+02:00 hh16 cifs.upcall: find_krb5_cc:
considering /tmp/krb5cc_3000032
2013-04-12T11:10:48.608414+02:00 hh16 cifs.upcall: find_krb5_cc:
/tmp/krb5cc_3000032 is owned by 3000032, not 3000034
2013-04-12T11:10:48.608948+02:00 hh16 cifs.upcall: find_krb5_cc:
considering /tmp/krb5cc_0
2013-04-12T11:10:48.609470+02:00 hh16 cifs.upcall: find_krb5_cc:
/tmp/krb5cc_0 is owned by 0, not 3000034
2013-04-12T11:10:48.610854+02:00 hh16 cifs.upcall: handle_krb5_mech:
getting service ticket for hh16.hh3.site
2013-04-12T11:10:48.615154+02:00 hh16 cifs.upcall: handle_krb5_mech:
obtained service ticket
2013-04-12T11:10:48.615189+02:00 hh16 cifs.upcall: Exit status 0
hh16:/tmp #

That seems fine except that the wrong uid:gid has been sent to the mount
for steve2 so he can't write to his cifs mounted folder.

To investigate this, I made his folder 0777 and then created a file in
the share:

hh16:/home/users # chmod 0777 steve2/
hh16:/home/users # su steve2
steve2@hh16:/home/users> cd /mnt/steve2
steve2@hh16:/mnt/steve2> touch testfile
steve2@hh16:/mnt/steve2> ls -l
total 1024
-rw-r--r-- 1 steve2 Domain Users 0 Apr 12 09:58 j
-rwxrwxr-x+ 1 3000019 users 0 Apr 12 11:14 testfile

cifs has sent 3000019:100 as the uid:gid It should send 3000034:20513

Question:
- why is user=steve specified on the mount command? (I am unix user
steve. steve2 is a domain user, but I'm doing the mount as root)
Probably because you're su'ing to root without clearing your
environment. If you don't specify a username, then mount.cifs will
scrape the value of $USER out of your environment and stuff that into
the field. It really matters little here though -- the username is
ignored when you use kerberos. All that matters is the ticket.

- What am I doing wrong?
At first glance, I have to wonder whether "steve2" is mapped to the
same uid on the client and server. It seems likely that on the client
that this krb5 user maps to 3000034, but on the server it maps to
3000019.

Hi Jeff
Yes. That was it. The server got the uid from idmap.ldb and the client
from AD. Or maybe the other way around. Anyway,I tried to force this with:
idmap_ldb use:rfc2307 = Yes
but that's the wrong syntax; but not identified by testparm:(

So, for the record, to pull uid:gid from AD and _not_ idmap:
[global] in smb.conf needs this syntax:
idmap_ldb:use rfc2307 = Yes

Personally, I think that all uid:gid should come from AD by default.

Note that it's not necessarily wrong for them to be mapped
inconsistently -- it just looks weird from the client. When you use
"multiuser" then it also turns off client-side permission checking and
leaves it up to the server.

If you were to change the ownership on the directory to 3000019 on the
server, then everything will likely also work correctly. It's just that
stat() calls would show the ownership as something else on the client.

Hi Jeff
We are keen to keep this as simple as possible. We are contemplating moving from nfs to cifs for our Linux clients and want it to 'just work', like it does with nfs. What you see on the server is what you get on the client. Pulling everything from AD seems logical: we really can't see why anyone would want to go down any other route. I'm thinking of the external idmap database which samba seems to like so much but which causes so much confusion, as exemplified over on the samba list. It must be said that without multiuser, we'd not consider the move to cifs, so thanks for the great work you've done to develop it. The main reason for doing so is that locking works when users have documents open on both Linux and windows clients. It _sometimes_ works with nfs. It's the sometimes that we can't have.
Steve

--
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




[Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux