[Samba] Building rpcclient statically linked?

pisymbol pisymbol at gmail.com
Mon Jun 18 19:53:21 UTC 2018

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
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?


More information about the samba mailing list