Bug 2512 - Conflicting UNIX and Samba permissions when UID/GID differ on server/client
Conflicting UNIX and Samba permissions when UID/GID differ on server/client
Status: RESOLVED FIXED
Product: CifsVFS
Classification: Unclassified
Component: user space tools
2.6
x86 Linux
: P3 normal
: ---
Assigned To: Jeff Layton
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-22 01:14 UTC by Jens Benecke
Modified: 2012-04-06 10:51 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jens Benecke 2005-03-22 01:14:03 UTC
Hello, 
 
we (SuSE Linux 9.1, Samba 3.0.9-2.6 on the server, Samba 3.0.9 and 3.0.11 on 
the clients) have this share to allow my boss access to his secretary's home 
directory: 
 
[home_secretary] 
        path = /home/secretary 
        browseable = no 
        force user = secretary 
        valid users = boss, myself 
        read only = no 
 
This should allow two people to access /home/secretary *as* user "secretary". 
However, when we 'smbmount' this share, the UNIX extensions seem to kick in 
and locally we are presented with secretary's UID/GID as they are on the 
server, which prevents writing to the directory, although the access rights 
*should* allow it. 
Mounting the share from Windows or via KDE's "smb://" protocol (which does not 
support UNIX extensions) works fine. The logs also show no errors, just login 
success. 
 
This could be solved by allowing disabling the UNIX extensions from the client 
side, but a) that would yet have to be implemented and b) that way you'd also 
lose symlinks and access rights, which is not a good idea. 
 
Thank you, 
 
Jens
Comment 1 Jens Benecke 2005-03-22 01:49:56 UTC
Just noticed, this also happens when I'm *not* using "force user". 
 
Mounting a share on a server which uses different UID/GIDs than are used 
locally, with UNIX extensions enabled, will make Linux locally believe that 
the user has no access rights, although the Samba authentication works fine 
and the user *should* be able to access the share fine. 
 
For example: 
# /etc/samba/smbfstab 
//filebox/home /home/RZ-home cifs username=jbenecke,password=XXXX,rw 
 
this mount succeeds, but is unuseable: 
 
drwx------   4  2083 10850    0 2005-02-02 10:55 RZ-home 
 
> LC_ALL=C touch RZ-home/file 
touch: cannot touch `RZ-home/file': Permission denied 
 
> id 
uid=501(jens) gid=100(users) 
 
 
One possible way to solve this problem would be to specify (if mounting as 
root) the UID/GID to *override* on the server side, even if UNIX extensions 
are used. Just disabling UNIX extensions for the client will also disable 
symlinks and so on, so is not really a solution. 
 
A more elegant solution would be to create a UID/GID mapping scheme. 
 
Thanks, 
 
Jens 
Comment 2 Gerald (Jerry) Carter 2005-03-22 03:49:55 UTC
Can you retest with the cifs fs ?  We don't actually support smbfs.  
You would need to talk the kernel maintainers.  However, cifs fs is 
under more active development.  See http://linux-cifs.sf.net/ for details.
Comment 3 Jens Benecke 2005-03-22 05:14:48 UTC
Hi, 
 
well if you read the smbfstab above, I *am* using CIFS, not SMBFS. Here is the 
mount status: 
 
//filebox/home on /home/RZ-home type cifs (rw,mand) 
 
Comment 4 Gerald (Jerry) Carter 2005-03-22 06:36:20 UTC
well then you are using smbmount :-)  Since that is only used with smbfs.
And it would help to file the bug against the correct product. :-)
Comment 5 Jens Benecke 2005-03-29 00:59:31 UTC
 
 
OK, because this also happens when mounting normal shares, without "force 
user", I changed the subject accordingly. Is anybody investigating this? 
 
Thanks! 
Comment 6 Steve French 2005-03-29 12:53:55 UTC
Before starting to prototype a solution, I would like to understand the uid
mapping now done in Linux for NFSv4 client.

Although I doubt that this facility could be reused directly, that needs to be
verified.
Comment 7 Jens Benecke 2005-06-20 02:12:50 UTC
Hi, 
 
is this bug still being investigated? I'd like to know if I can help in any 
way. 
 
Thanks! 
Comment 8 Kostanbaev Sergey 2006-03-15 15:01:13 UTC
Hello, sorry for my English, i am using Debian 3.1 server & clients
when i mounting shares whith username sergu1 (UID=1005 GID=1003 on server)

in /etc/fstab
//SFLABS/sergu1 /home/serg/sergu        cifs    iocharset=koi8-r,ip=192.168.128.1,user=sergu1,password=****

after mounting

serg@gamma:~/sergu$ mkdir ttt    
serg@gamma:~/sergu$ ls -l
drwx------   2 1005 1003        0 2006-03-15 23:50 ttt
serg@gamma:~/sergu$ rmdir ttt
serg@gamma:~/sergu$ touch ddd
touch: cannot touch `ddd': Permission denied

On mounting system I can create diretory, but no file.

Is any way to perform UID mapping on mounted system?
Comment 9 Rudolf Kollien 2006-12-15 07:51:02 UTC
We now run into the same problem. After upgrading our LinkSys NAS to new firmware, now there runs a samba 3.0.x server for the SMB shares (previously samba 2.2x). We have user shares mounted with automount into the users home dir. Since the update now, the files and directories now cannot be writen/created anymore as the uid/gid are different. This problem doesn't occur with our other server<->client-combinations, as we have yp/nis running, so all "normal" system use the same uid/gid. Using a nativ windooze client (w2k/xp etc.) all running normal. Using KDEs kio also is ok (as i read, it doesn't understand the Unix extensions). Our workaround now is to create a gid on network identical to the gid used on the NAS and assigning it to the users who mount the NAS shares. So they can write/create files. But i think this isn't what we all want. There should/must be a uid/gid mapping mechanism. Maybe based on the user/group NAME.
Using the uid=xxxx,gid=xxxxx option on the mount.cifs command line doesn't help.

We are using samba 3.0.23d on the servers/clients. mount.cifs varies between 1.10-3.0.23d-0.1.38-1074:1075-SUSE-SL9.3 on the SuSE 9.3 clients and 1.10-3.0.23d-5.1.39-1084-SUSE-CODE10 on the SuSE 10.x. The LinkSys NAS now runs samba 3.0.20.

The automount options are similar to:
-fstype=cifs,credentials=/home/xyz/.mnt/login.txt,uid=xyz,iocharset=utf8,codepage=cp8
50    \\\\nas01\\&

There seems to be a identical bugid 4287
Comment 10 ZeruelX of Zinj 2007-11-25 20:23:32 UTC
(In reply to comment #1)
> Mounting a share on a server which uses different UID/GIDs than are used 
> locally, with UNIX extensions enabled, will make Linux locally believe that 
> the user has no access rights, although the Samba authentication works fine 
> and the user *should* be able to access the share fine. 

You can use the "noperm" mount option, which disables enforcement of Unix permissions and ownership on the local side.
Comment 11 Jeff Layton 2009-07-26 08:02:23 UTC
Yes, noperm may be the best option here for now. Eventually we'd like to add some sort of ID mapping to cifs but it doesn't exist today.
Comment 12 Shirish S. Pargaonkar 2009-12-22 15:17:31 UTC
Looking into this.  What sort of ID mapping can be used.
For example, if I login as user xyz (-o user=xyz) but user xyz on the server
and client have different ids (uid) or gids on server and client have different
group names, what kind of mapping you do?
It is also possible that the same group exists on server and client but
gid of the group on the server is taken up by a different group on the client.
Comment 13 Shirish S. Pargaonkar 2010-01-05 17:45:09 UTC
I am not sure whether any kind of uid mapping is going to help.
When you have user mounted shares, they are mounted as if with mount option
uid=1234 and gid=5678 of that user=abcd.
And I do not understand what it means uid/gid mapping here, are uid/gid
from the server are mapped to uid/gid on the client?
With uid= specified on the mount command for user mounts, not sure whether 
any uid/gid (server) to uid/gid (client) mapping will help.
Comment 14 Shirish S. Pargaonkar 2010-01-06 07:02:11 UTC
Regarding comment #8, inspite of the warning about permission denied while
doing 'touch ddd', the file does get created on the server, it just can't be
modified by the user 'serg' (metadata modification fails, file can't be
written to) in any way.
Comment 15 Jeff Layton 2010-01-06 07:25:13 UTC
(In reply to comment #13)
> I am not sure whether any kind of uid mapping is going to help.
> When you have user mounted shares, they are mounted as if with mount option
> uid=1234 and gid=5678 of that user=abcd.
> And I do not understand what it means uid/gid mapping here, are uid/gid
> from the server are mapped to uid/gid on the client?
> With uid= specified on the mount command for user mounts, not sure whether 
> any uid/gid (server) to uid/gid (client) mapping will help.
> 

idmapping is going to be tricky...

It's somewhat easier with NFSv4 since it sends text user id's across the wire and then the receiving side can determine how to map that to a local uid. CIFS unix extensions send a numeric uid however (in response to a QPathInfo call for instance). So to do some sort of uid mapping you need to:

a) query the server somehow and ask "to what username does this uid map?"

...and then upcall to userspace somehow and ask:

b) "what's the local uid for this username?"

With that you could then write an inode "permission" op that could enforce permissions locally. The catch here is that no call for "a" exists yet, so you'll need to extend the protocol.

A much better plan IMO would be to implement multi-session mounts:

http://wiki.samba.org/index.php?title=LinuxCIFS_Multisession_Mount

...and just leave permissions enforcement to the server altogether. That's a much bigger project however.
Comment 16 Shirish S. Pargaonkar 2010-01-07 17:57:17 UTC
(In reply to comment #15)
> (In reply to comment #13)

> The catch here is that no call for "a" exists yet, so
> you'll need to extend the protocol.

perhaps if a (Samba) server supports named pipes like lsarpc and samr,
may be winbindd can/does identify a user name for a given uid/sid.
Thus it may not be necessary to extend the protocol.
Comment 17 Jeff Layton 2012-04-06 10:51:14 UTC
The current cifs client now supports multiuser mounts with both krb5 and username/password based authentication. I think that's as good as a solution
as you're going to get with this, given the protocol limitations.

At this point, I'll go ahead and close this as RESOLVED FIXED based on that,
but feel free to reopen and we can discuss it further if you like.