Bug 1853 - no uid translation with unix extensions
Summary: no uid translation with unix extensions
Status: CLOSED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: libsmbclient (show other bugs)
Version: 3.0.6
Hardware: All Linux
: P3 normal
Target Milestone: none
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-29 23:07 UTC by Tobias Oetiker
Modified: 2005-08-24 10:21 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Oetiker 2004-09-29 23:07:56 UTC
Hi jerry,

here is the bug report you asked me to submit at the SANE BoF

If I mount a samba share with unix extensions, and my uid is not the same on the
server and the client, I end up with a mount where the files that belong to me
on the server do seemingly not belong to me on the client. Even though access is
no problem applecations tend to get seriously confiused when I try to open a
directory that belongs to someone else with permissions 700.
Comment 1 Steve French 2004-09-30 08:35:07 UTC
The cifs vfs mount options now include options for:
1) disabling the client side permission check
2) overriding the default behavior on newly created files (from that of the 
server to that of the client)

see fs/cifs/README

Are you proposing something like the new nfs uid mapping client 
pseudofilesystem approach to make this better? or ties to winbind? 
Comment 2 Tobias Oetiker 2004-09-30 23:19:55 UTC
here is an example

* Machines A and B have different username/uid mappings

* User "foo" on machine A uses cifs to connect to the account of user
  "bar" on machine B.

* "foo" knows the right password and gets connected to the share of "bar"
  on machine B.

* I would now expect that the files belonging to "bar" would appear as
  belonging to "foo" when seen on machine "A" because only this will
  ensure that unix applications accessing the files will behave correctly.
  
* I could imaging that the fact that "bar" has full access is established
  via a fake ACL on the client side, but this seems like a lot more effort
  than required.

 
Comment 3 Jeremy Brown 2005-01-11 14:43:57 UTC
I *think* this is the issue I'm running into as well.  I mount a remote share
from our company file server on my Linux laptop using my remote un/pw, and I
can't actually access any of my files because they have different UIDs.

I just found out yesterday that this was caused by UNIX extensions being turned
on at the server.  I turned them off (luckily I happen to be one of our SAs, so
I can actually do that), and it works as expected.

Two thoughts:

1) Personally I think an adequate fix for this would be to have smbfs support an
option for turning off UNIX extensions, even if they're turned on at the server.
 As it is I think I need server access in order to make my linux client connect
to the server the right way for me, which is without extra UNIX extensions (I'm
not 100% sure of that...and if this isn't the case, someone please enlighten me).

2) It seems like having your UIDs be the same on local and remote machines is
probably not as common as having these UIDs be different (might want to poll
some users to see).  Should UNIX extensions maybe be turned off by default?  I
know for my particular set of Samba use cases, I'm probably never going to want
or need them on (seems like this would be more handy for some sort of NFS-type
setup), but I don't know other users' usage patterns.
Comment 4 Steve French 2005-01-11 16:16:45 UTC
No need to change smbfs, its replacement cifs vfs already has such an option 
("echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled" will disable them on the 
client)
Comment 5 Gerald (Jerry) Carter (dead mail address) 2005-02-11 08:34:34 UTC
closing.  appears to be resolved aor at least a workaround is in place.
Comment 6 Gerald (Jerry) Carter (dead mail address) 2005-08-24 10:21:32 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.