Bug 8933 - Regression after security update - linux client unable to delete files
Regression after security update - linux client unable to delete files
Status: NEW
Product: Samba 3.5
Classification: Unclassified
Component: File services
3.5.6
All All
: P5 normal
: ---
Assigned To: Volker Lendecke
Samba QA Contact
http://bugs.debian.org/cgi-bin/bugrep...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-11 12:53 UTC by Christian Perrier
Modified: 2012-05-11 13:30 UTC (History)
0 users

See Also:


Attachments
Debug log (315.16 KB, application/octet-stream)
2012-05-11 12:53 UTC, Christian Perrier
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Perrier 2012-05-11 12:53:15 UTC
Bug reported in Debian. I was balanced about forwarding it because the bug was experienced by our user with the 3.5.6 version of version and he has no real way to try reproducing it with 3.6 (the server being a production server).

The bug appeared, according to our user after he upgraded from the 2:3.5.6~dfsg-3squeeze2 version of Debian packages to 2:3.5.6~dfsg-3squeeze4.

Such updates are usually made of either security fixes...or fixes for important issues where we cherry-pick fixes.

The changelog between the two versions is:
samba (2:3.5.6~dfsg-3squeeze4) stable-proposed-updates; urgency=low

  * Document the newly introduced "map untrusted to domain" parameter
    and its default value that can lead to disruptive behavioral
    changes when upgrading from pre-3.5 versions.
    Closes: #623190
  * Fix "tdb2.so undefined symbol: dyn_get_STATEDIR" by fixing a typo
    in fhs-filespath.patch. Closes: #629183, LP: #789097

 -- Christian Perrier <bubulle@debian.org>  Sat, 11 Jun 2011 11:05:52 +0200

samba (2:3.5.6~dfsg-3squeeze3) stable-proposed-updates; urgency=low

  * Cherry-picked fixes from samba 3.5.8 for some important bugs:
    - Upstream bug 7567: printing from Windows 7 fails with 0x000003e6.
      Closes: #617429
    - Upstream bug 6727: printer device settings not saved for normal
      domain users. Closes: #611177       
    - Upstream bug 7777: winbind leaks gids with idmap ldap backend
      Closes: #613624
    - Upstream bug 7880: rpcclient deldriver does not remove drivers
      from all architectures.

 -- Christian Perrier <bubulle@debian.org>  Sun, 13 Mar 2011 08:07:42 +0100


The problem (our user is speaking):
"Now I cannot delete any file from samba share using linux samba client, even the file that has been created by the same user and the same client just before. I don't use any extended ACLs, sticky bits or so.
I don't see any problem using WindowsXP clients."

After some exchanges, he sent us a full lvel 10 log where the user created a test.txt file, then attempted to delete it. I attach it to this bug report. From my understanding, the problem  shows up around line 4443.

Do you think something can be investigated or does it ring a bell to you? I'm sorry we can't provide a report with a more recent version of samba, but that's apparently not possible for our user...
Comment 1 Christian Perrier 2012-05-11 12:53:52 UTC
Created attachment 7554 [details]
Debug log
Comment 2 Jeremy Allison 2012-05-11 13:30:55 UTC
Here is the authentication token of the connected user:

  NT user token of user S-1-22-1-10249
  contains 6 SIDs
  SID[  0]: S-1-22-1-10249
  SID[  1]: S-1-5-21-2222734727-3523169228-4078589058-514
  SID[  2]: S-1-1-0
  SID[  3]: S-1-5-2
  SID[  4]: S-1-5-11
  SID[  5]: S-1-22-2-10014
  SE_PRIV  0x0 0x0 0x0 0x0

Note the primary SID is a Samba-UNIX-style SID (i.e. no mapping from a Windows name has been done).

Now look at the unlink call that fails. At line 4445 we see the file has permissions:

  canon_ace index 0. Type = allow SID = S-1-5-21-2222734727-3523169228-4078589058-21249 uid 10249 (zalohymail) SMB_ACL_USER_OBJ ace_flags = 0x0 perms rwx
  canon_ace index 1. Type = allow SID = S-1-22-2-0 gid 0 (root) SMB_ACL_GROUP_OBJ ace_flags = 0x0 perms r-x
  canon_ace index 2. Type = allow SID = S-1-1-0 other SMB_ACL_OTHER ace_flags = 0x0 perms r-x

Note that the owning user is S-1-5-21-2222734727-3523169228-4078589058-21249, which is the same as UNIX user uid 10249 - the problem is that when this user logged in the uid 10249 isn't being mapped into SID S-1-5-21-2222734727-3523169228-4078589058-21249, but into SID S-1-22-1-10249.

That's the issue. The log doesn't show the user login information, so there isn't enough information to know why the lookup isn't being done.

I'd suggest retrying with a later Samba version to see if the mapping of the incoming user is being done to the correct SID.