On Mon, 2018-06-18 at 10:35 -0400, pisymbol via samba wrote:> Small addendum, I did try: > > ./configure --nonshared-binary=ALL > > ERROR: source source3/smbd/notify_msg.c is in more than one subsystem of > target 'smbstatus': ['smbd_base.objlist', 'smbstatus.objlist'] > > This is CentOS 7.5. > > -apsBuilding more than smbd and smbtorture nonshared is simply not tested. The configure incantation for those is --nonshared- binary=smbtorture,smbd/smbd You can try --nonshared-binary=rpcclient but I suspect it will fail similarly, because so far nobody has done the work to ensure that each C file is only in one subsystem. Now, you have actually identified a bug, for smbstatus notify_msg.c is listed twice in the wscript_build file. Ideally Samba (or at least larger parts of Samba) would build as you suggest because it does identify real-world issues. While this file has no static data, if a C file is linked in twice with static data the results can be un-desired.>From here however you can only try, and work to break up our dependencylist into a directed acyclic graph. This is harder than is looks! Finally, perhaps you could detail what you are hoping to achieve with a static rpcclient? We may have another way to assist you with your aims. Sorry, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
On Mon, Jun 18, 2018 at 2:39 PM, Andrew Bartlett <abartlet at samba.org> wrote:> On Mon, 2018-06-18 at 10:35 -0400, pisymbol via samba wrote: > > Small addendum, I did try: > > > > ./configure --nonshared-binary=ALL > > > > ERROR: source source3/smbd/notify_msg.c is in more than one subsystem of > > target 'smbstatus': ['smbd_base.objlist', 'smbstatus.objlist'] > > > > This is CentOS 7.5. > > > > -aps > > Building more than smbd and smbtorture nonshared is simply not tested. > > The configure incantation for those is --nonshared- > binary=smbtorture,smbd/smbd >This is what I feared!> > You can try --nonshared-binary=rpcclient but I suspect it will fail > similarly, because so far nobody has done the work to ensure that each > C file is only in one subsystem. > > Now, you have actually identified a bug, for smbstatus notify_msg.c is > listed twice in the wscript_build file. Ideally Samba (or at least > larger parts of Samba) would build as you suggest because it does > identify real-world issues. While this file has no static data, if a C > > file is linked in twice with static data the results can be un-desired. >Totally understood. I figured it was a bug but I'm not a waf expert to be confident in that assessment.> > From here however you can only try, and work to break up our dependency > list into a directed acyclic graph. This is harder than is looks! > > Finally, perhaps you could detail what you are hoping to achieve with a > static rpcclient? We may have another way to assist you with your > aims. >Andrew, very simply, I need a way to dump the raw share ACL. Currently, I have a modified version of rpcclient that issues an info level 502 request but instead of parsing the share security descriptor for rpcclient to parse, it copies the SD as a raw binary buffer that I can print to stdout for another tool to pickup and store for offline purposes. This is done by modifying the generated ndr files (ndr_security.c) after they are converted from their IDL ones (instead of creating an in-core representation of the SD, I just copy it out as is). What is happening NOW though is that because the team has split up different subsystems into their own RPM, the changes I made are not actually getting incorporated into the final binary because the RPC stuff is part of the samba-client-libs. I got fooled initially by all of this because of this screwy thing you guys do (I say that with a lot of love!) with RPATH whereby the built binaries in the tree have RPATHs set to within the tree itself but the final installed executable have their RPATHs set to /usr/lib or whatever is the default etc. It drove me a little batty before looking at the waf install rules (it would work when executed from within the build tree but then subsequently fail if I copied the binary somewhere else etc.). So here we go, very simply: Can you tell me a way I can get access to the raw SD of a CIFS share (info level 502) without modifying rpcclient? If not, what would be the best approach then? -aps
On Mon, Jun 18, 2018 at 3:53 PM, pisymbol <pisymbol at gmail.com> wrote:> > > On Mon, Jun 18, 2018 at 2:39 PM, Andrew Bartlett <abartlet at samba.org> > wrote: > >> On Mon, 2018-06-18 at 10:35 -0400, pisymbol via samba wrote: >> > Small addendum, I did try: >> > >> > ./configure --nonshared-binary=ALL >> > >> > ERROR: source source3/smbd/notify_msg.c is in more than one subsystem of >> > target 'smbstatus': ['smbd_base.objlist', 'smbstatus.objlist'] >> > >> > This is CentOS 7.5. >> > >> > -aps >> >> Building more than smbd and smbtorture nonshared is simply not tested. >> >> The configure incantation for those is --nonshared- >> binary=smbtorture,smbd/smbd >> > > > This is what I feared! > > >> >> You can try --nonshared-binary=rpcclient but I suspect it will fail >> similarly, because so far nobody has done the work to ensure that each >> C file is only in one subsystem. >> >> Now, you have actually identified a bug, for smbstatus notify_msg.c is >> listed twice in the wscript_build file. Ideally Samba (or at least >> larger parts of Samba) would build as you suggest because it does >> identify real-world issues. While this file has no static data, if a C >> >> file is linked in twice with static data the results can be un-desired. >> > > Totally understood. I figured it was a bug but I'm not a waf expert to be > confident in that assessment. > > >> >> From here however you can only try, and work to break up our dependency >> list into a directed acyclic graph. This is harder than is looks! >> >> Finally, perhaps you could detail what you are hoping to achieve with a >> static rpcclient? We may have another way to assist you with your >> aims. >> > > Andrew, very simply, I need a way to dump the raw share ACL. > > Currently, I have a modified version of rpcclient that issues an info > level 502 request but instead of parsing the share > security descriptor for rpcclient to parse, it copies the SD as a raw > binary buffer that I can print to stdout for another tool > to pickup and store for offline purposes. >Eee gad. What I meant was: I have a binary based off of rpclient that prints out the raw share SD as a binary stream instead of trying to parse it into human readable format (the default behavior). That is what I'm after. Hopefully that makes more sense. Cheers! -aps