Bug 5475 - SID to owner name mapping fails
SID to owner name mapping fails
Product: Samba 3.0
Classification: Unclassified
Component: libsmbclient
Other Windows XP
: P3 normal
: none
Assigned To: Derrell Lipman
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2008-05-19 06:01 UTC by Veeral Shah
Modified: 2009-01-03 09:48 UTC (History)
1 user (show)

See Also:

Test "c" code (1.92 KB, text/plain)
2008-06-03 02:15 UTC, Veeral Shah
no flags Details
The debug output. (190.42 KB, text/plain)
2008-06-03 02:16 UTC, Veeral Shah
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Veeral Shah 2008-05-19 06:01:24 UTC
I am facing some issue with smbc_getxattr() API. I am interested in "system.nt_sec_desc.owner_name+" attribute. The API usually works correctly as long as smbc_stat() is not invoked.. 

Once the code invokes smbc_stat() to get struct stat corresponding to the target files, subsequent invocations of smbc_getxattr(.., "system.nt_sec_desc.owner_name+", ..) gives incorrect results. On subsequent invocation, the call just returns SID (instead of user readable name).

Is this a known issue??
Comment 1 Derrell Lipman 2008-05-30 09:47:36 UTC
I assume that you just had a typo in this bug report, and you intended to say "system.nt_sec_desc.owner+" not "system.nt_sec_desc.owner_name+".

I am unable to reproduce this problem.  I've modified examples/libsmbclient/testacl in v3-3-test branch to do what I believe you're saying.  The command line for testacl would be something like this:

./testacl -R -g 'system.nt_sec_desc.owner+' 'smb://myserver/c%24/boot.ini'

The -g <acl> flag is to GET the specified acl, and the -R flag is to RETRY getting the specified acl again after issuing an smbc_stat() call on the specified file.

Please test with this application and let me know if you encounter the same problem.  If not, I suspect that something in your application is scribbling on memory.


Comment 2 Veeral Shah 2008-06-03 02:15:52 UTC
Created attachment 3328 [details]
Test "c" code

CLI: ./test <remote_file_name>
Comment 3 Veeral Shah 2008-06-03 02:16:31 UTC
Created attachment 3329 [details]
The debug output.
Comment 4 Veeral Shah 2008-06-03 02:20:57 UTC
Thanks for your comments Darrell. Yes, I intended to say "system.nt_sec_desc.owner+". 

I will run the test benchmark code to reproduce the issue as you suggested. Meanwhile here is a sample test code that is giving problem on my setup (kindly ignore the code sanity). You may give it a try too. It takes the remote file name  as an input argument. I am calling smbc_stat() multiple times between two invocations of smbc_getxattr(). 
Comment 5 Derrell Lipman 2008-06-03 13:17:33 UTC
Your application works fine for me.  I wonder if you have a compilation consistency problem.  The size of struct stat differs depending upon compile-time options.  It's possible that libsmbclient is scribbling on your memory or your app is scribbling on libsmbclient's memory if they don't both use the same structure sizes.

Are you compiling your own libsmbclient library?  If so you can do this test:

Save your test program in examples/libsmbclient as x.c and patch the Makefile like this:

diff --git a/examples/libsmbclient/Makefile b/examples/libsmbclient/Makefile
index 7415f4f..81500b5 100644
--- a/examples/libsmbclient/Makefile
+++ b/examples/libsmbclient/Makefile
@@ -94,6 +94,10 @@ testwrite: testwrite.o
 	@echo Linking testwrite
 	$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBSMBCLIENT) -lpopt
+x: x.o
+	@echo Linking x
+	$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $< $(LIBSMBCLIENT) -lpopt
 	make -C smbwrapper
Now, try running "./x <path>" and confirm that it works as expected.  I believe it will.  You can then look at the compile options used to compile x.c so you know what options you must use for your real app.

If you're using a pre-compiled libsmbclient library, you'll need to find out what options it was built with.

(Inconsistency between how the library is built and how the application is compiled is an ongoing problem that I really want to come up with a descent solution for.)

Comment 6 Derrell Lipman 2009-01-03 09:48:43 UTC
No reply for six months.  Please re-open if necessary.