Bug 6194 - Wrong UID / GID + mount.cifs + krb5
Summary: Wrong UID / GID + mount.cifs + krb5
Status: RESOLVED FIXED
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: kernel fs (show other bugs)
Version: 2.6
Hardware: Other Linux
: P3 normal
Target Milestone: ---
Assignee: Jeff Layton
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-17 07:31 UTC by Stepanov Andriy
Modified: 2009-07-21 10:56 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stepanov Andriy 2009-03-17 07:31:24 UTC
Client & server sides has same version of samba.

From manpage SMB.CONF(5):
Default: unix extensions = yes

Make sure that server side properly configured:
# testparm -v -s 2>/dev/null | grep -i 'unix extensions'
unix extensions = Yes

Some quotation from MOUNT.CIFS(8) about "uid=arg" option:

sets the uid that will own all files on the mounted filesystem

If the server and client are in the same domain (e.g. running winbind or
nss_ldap) and the server supports the Unix Extensions then the uid and gid can
be retrieved from the server (and uid and gid would not have to be specifed on
the mount

For servers which do not support the CIFS Unix extensions, the default uid (and
gid) returned on lookup of existing files will be the uid (gid) of the person
who executed the mount (root, except when mount.cifs is configured setuid for
user mounts) unless the "uid=" (gid) mount option is specified. 

If I don't supply "uid=arg" option, I see real UIDs (as on server side)

[stanv@stanv vid3]$ cifsmount //umka.malta.altlinux.ru/srv share2 --verbose
Password: 

mount.cifs kernel mount options
unc=//umka.malta.altlinux.ru\srv,ip=10.2.1.16,user=stanv,pass=q1,ver=1

$ find share2 -printf '%u(%U) %g(%G) %p\n'
root(0) root(0) share2
mumu(501) camera(501) share2/for_mumu
mumu(501) camera(501) share2/for_mumu/dfadfsdf
mumu(501) camera(501) share2/for_mumu/rrr
stanv(500) stanv(500) share2/for_stanv
stanv(500) stanv(500) share2/for_stanv/sdfsdf
stanv(500) stanv(500) share2/for_stanv/bbbbb
root(0) root(0) share2/123

т.е. в смонтированом ресурсе мы видим ID владельцев, каковы они являются на
сервере.

so, on client side i can see real file owners.

Now, do the same, but mount using Kerberos authentication.

$ kinit 
Password for stanv@MALTA.ALTLINUX.RU: 

$ klist 
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: stanv@MALTA.ALTLINUX.RU

Valid starting     Expires            Service principal
03/17/09 15:24:13  03/17/09 22:04:10  krbtgt/MALTA.ALTLINUX.RU@MALTA.ALTLINUX.RU


[stanv@stanv vid3]$ cifsmount //umka.malta.altlinux.ru/srv share2 --verbose
-osec=krb5,guest
parsing options: sec=krb5,guest

mount.cifs kernel mount options
unc=//umka.malta.altlinux.ru\srv,ip=10.2.1.16,user=stanv,ver=1,sec=krb5,guest,uid=500,gid=500 

$ find share2 -printf '%u(%U) %g(%G) %p\n'
stanv(500) stanv(500) share2
stanv(500) stanv(500) share2/for_mumu
stanv(500) stanv(500) share2/for_mumu/dfadfsdf
stanv(500) stanv(500) share2/for_mumu/rrr
stanv(500) stanv(500) share2/for_stanv
stanv(500) stanv(500) share2/for_stanv/sdfsdf
stanv(500) stanv(500) share2/for_stanv/bbbbb
stanv(500) stanv(500) share2/123

As wee can see, for all files owner is stanv (500).
But, stanv(500) can write/change files in hare2/for_stanv folder.

Option "guest" supplied for "Don't ask the password" (with Kerberos auth we don't need password).

This all because kernel catch uid=500,gid=500, about wee talk before.

CLIENT SYSTEM INFO:

$ cat /proc/fs/cifs/LinuxExtensionsEnabled 
1

$ /usr/sbin/cifs.upcall -v
version: 1.2

$ cifsmount -V
mount.cifs version: 1.10-3.0.33

# which cifsmount
/usr/bin/cifsmount

[root@stanv ~]# rpm -qf /usr/bin/cifsmount
samba-client-3.0.33-alt2

[root@stanv ~]# rpm -qi samba-client
Name        : samba-client                 Relocations: (not relocatable)
Version     : 3.0.33                            Vendor: ALT Linux Team
Release     : alt2                          Build Date: Thu Mar  5 18:47:58 2009
Install date: Thu Mar  5 18:51:15 2009      Build Host: stanv.malta.altlinux.ru
Group       : Networking/Other              Source RPM: samba-3.0.33-alt2.src.rpm
Size        : 15304444                         License: GNU GPL
Packager    : Alexander Bokovoy <ab@altlinux.ru>
URL         : http://www.samba.org/
Summary     : Samba (SMB/CIFS) client programs
Description :
Samba-client provides some SMB clients, which complement the built-in
SMB filesystem in Linux. These allow the accessing of SMB shares.
Support for printing to SMB printers is in Samba-client-cups package.
Comment 1 Stepanov Andriy 2009-03-17 07:33:02 UTC
Kernel helper cifs.upcall beckported from Samba 3.2
Comment 2 Jeff Layton 2009-04-03 07:45:16 UTC
This is a real problem without a nice easy solution that won't break backward compatibility:

The problem is that we use the uid= option for two things:

1) to set the ownership of files on a share
Comment 3 Jeff Layton 2009-04-03 07:49:40 UTC
Oops, submitted the last comment too fast...

The problem is that uid= means too much:

1) it tells the kernel who's credcache it should use to generate the spnego blob

2) it tells the kernel what the default ownership of files should be when unix extensions are disabled

3) when they are enabled, it clobbers the uid's sent by the server

So there's currently no way to say "I want to use krb5 creds from an unprivileged user's credcache and I want file ownership information from the server"

The right fix is probably to change the behavior so that #3 doesn't happen, and maybe add another mount option that allows someone to get that behavior (forceuid/forcegid or something).
Comment 4 Jeff Layton 2009-07-21 10:56:48 UTC
There's now a patch in place in mainline kernels that should fix this.

It changes the behavior such that the uid=/gid= options do not override the ownership info provided by the server by default. If you mount with forceuid/forcegid however it enables the legacy behavior.

This should be fixed in 2.6.31 when it's released. I'll go ahead and close this bug as FIXED. Please reopen if you find that 2.6.31-rc3 or above doesn't fix it for you.