svn commit: samba r264 - in branches/tmp/VOYAGER/source:
groupdb include libsmb nsswitch passdb smbd
idra at samba.org
Mon Apr 19 15:54:45 GMT 2004
On Mon, 2004-04-19 at 16:34, Volker.Lendecke at SerNet.DE wrote:
> On Mon, Apr 19, 2004 at 09:46:06AM +0200, Simo Sorce wrote:
> > The problem is that there's people that may be running winbindd only, no
> > smbd.
> That's the only really valid point here, I think. Maybe I will fork a smbd off
Not sure it is a wise thing.
People running only winbind expect only winbind running, not another
demon that opens up 4 ports on all interfaces, unless you intend also to
make that smbd only listening on the domain socket when invoked by
But at this point I do not see why not simply linking directly to the
functions you need as this just seem a loose way to link winbindd to
smbd functions :-)
I'm not against the idea of smbd using a socket (already done for the
buildfarm, just reuse that code please) or winbindd communicating with
smbd. Just asking if that is the right thing to do.
> > Plus adding a new comunication layer may lead to other bugs. Linking
> > directly to the code instead keeps it unique and simple.
> None of this communication layers is new, except for a different address family
> and connect() syscall. We do have winbind_rpc.c and srv_samr_nt.c already. If
> these break, we have other problems to take care of.
> Having smbd listen on unix domain might also open the door for easier local
> administration. Connecting on a protected unix-domain socket might
> automatically assume root privilege as you are root anyway. This means you can
> use 'net' without always typing in your password.
> Just an idea...
Simo Sorce - idra at samba.org
Samba Team - http://www.samba.org
Italian Site - http://samba.xsec.it
More information about the samba-technical