netbsd# /usr/pkg/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.11 (Sep 15 2008 00:03:54) $ root@netbsd.dmarkey.com: /usr/pkgsrc/databases/openldap-server/work/openldap-2.4.11/servers/slapd
netbsd# ldapsearch -x -H ldapi:// -b '' -s base -LLL supportedSASLMechanisms dn:
External isnt listed.
I assume that the unix socket API is slightly different.:
man unix
The LOCAL_CREDS option may be enabled on a SOCK_DGRAM or a SOCK_STREAM socket. This option provides a mechanism for the receiver to receive the credentials of the process as a recvmsg(2) control message. The msg_con- trol field in the msghdr structure points to a buffer that contains a cmsghdr structure followed by a variable length sockcred structure, defined in <sys/socket.h> as follows:
struct sockcred { uid_t sc_uid; /* real user id */ uid_t sc_euid; /* effective user id */ gid_t sc_gid; /* real group id */ gid_t sc_egid; /* effective group id */ int sc_ngroups; /* number of supplemental groups */ gid_t sc_groups[1]; /* variable length */ };
The LOCAL_PEEREID option may be used with getsockopt(2) to get the PID and effective user and group IDs of a SOCK_STREAM peer when it did connect(2) or bind(2). The returned structure is
struct unpcbid { pid_t unp_pid; /* process id */ uid_t unp_euid; /* effective user id */ gid_t unp_egid; /* effective group id */ }; as defined in <sys/un.h>.
The SOCKCREDSIZE() macro computes the size of the sockcred structure for a specified number of groups. The cmsghdr fields have the following val- ues:
cmsg_len = sizeof(struct cmsghdr) + SOCKCREDSIZE(ngroups) cmsg_level = SOL_SOCKET cmsg_type = SCM_CREDS
Any ideas?
Howard i assume you would be an authority to answer this one.
Thanks.
David Markey wrote:
netbsd# /usr/pkg/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.11 (Sep 15 2008 00:03:54) $ root@netbsd.dmarkey.com:/usr/pkgsrc/databases/openldap-server/work/openldap-2.4.11/servers/slapd
netbsd# ldapsearch -x -H ldapi:// -b '' -s base -LLL supportedSASLMechanisms dn:
External isnt listed.
Pretty sure none of what you quoted below is supported (yet). As far as I knew, the *BSDs all provided a native getpeereid() function so nothing else was needed. At least, FreeBSD and OpenBSD do. If NetBSD doesn't, then I suggest you submit an ITS to get one of the below APIs supported.
I assume that the unix socket API is slightly different.:
man unix
The LOCAL_CREDS option may be enabled on a SOCK_DGRAM or a SOCK_STREAM socket. This option provides a mechanism for the receiver to receive the credentials of the process as a recvmsg(2) control message. The msg_con- trol field in the msghdr structure points to a buffer that contains a cmsghdr structure followed by a variable length sockcred structure, defined in <sys/socket.h> as follows:
struct sockcred { uid_t sc_uid; /* real user id */ uid_t sc_euid; /* effective user id */ gid_t sc_gid; /* real group id */ gid_t sc_egid; /* effective group id */ int sc_ngroups; /* number of supplemental groups */ gid_t sc_groups[1]; /* variable length */ };
The LOCAL_PEEREID option may be used with getsockopt(2) to get the PID and effective user and group IDs of a SOCK_STREAM peer when it did connect(2) or bind(2). The returned structure is
struct unpcbid { pid_t unp_pid; /* process id */ uid_t unp_euid; /* effective user id */ gid_t unp_egid; /* effective group id */ }; as defined in <sys/un.h>.
The SOCKCREDSIZE() macro computes the size of the sockcred structure for a specified number of groups. The cmsghdr fields have the following val- ues:
cmsg_len = sizeof(struct cmsghdr) + SOCKCREDSIZE(ngroups) cmsg_level = SOL_SOCKET cmsg_type = SCM_CREDS
On Sun, Sep 14, 2008 at 09:41:51PM -0700, Howard Chu wrote:
Pretty sure none of what you quoted below is supported (yet). As far as I knew, the *BSDs all provided a native getpeereid() function so nothing else was needed. At least, FreeBSD and OpenBSD do. If NetBSD doesn't, then I suggest you submit an ITS to get one of the below APIs supported.
According to changelogs, LOCAL_CREDS has been implemented ten years ago on NetBSD. I have nothing about getpeerid(), though.
One thing that might explain the mess, from <sys/un.h>: /* * Socket options for UNIX IPC domain. */ #if defined(_NETBSD_SOURCE) #define LOCAL_CREDS 0x0001 /* pass credentials to receiver */ #define LOCAL_CONNWAIT 0x0002 /* connects block until accepted */ #endif
I don't know the background, but I assume that this is not standard, and that one wanted to avoid namespace pollution. Unfortunately, that breaks in OpenLDAP, servers/slapd/daemon.c:
#ifdef LOCAL_CREDS { int one = 1; setsockopt( s, 0, LOCAL_CREDS, &one, sizeof( one ) ); } #endif /* LOCAL_CREDS */
Adding a #define _NETBSD_SOURCE may help, but it can also open a can of worms.
Emmanuel Dreyfus writes:
One thing that might explain the mess, from <sys/un.h>: /*
- Socket options for UNIX IPC domain.
*/ #if defined(_NETBSD_SOURCE) #define LOCAL_CREDS 0x0001 /* pass credentials to receiver */ #define LOCAL_CONNWAIT 0x0002 /* connects block until accepted */ #endif (...) Adding a #define _NETBSD_SOURCE may help, but it can also open a can of worms.
Well, to get LOCAL_CREDS it looks like you'll have to open that can of worms. I suggest you try ./configure --enable-<everything under the sky> CPPFLAGS=_NETBSD_SOURCE and report how it works. Or if it doesn't, see if ./configure --disable-<everything under the sky> CPPFLAGS=_NETBSD_SOURCE helps, in case that helps narrow down the problems.
Should probably compile with plenty of compiler warnings (set in CFLAGS) and look for anything which didn't show up with the same warnings but without _NETBSD_SOURCE.
that doesnt seem to be working
checking for C compiler default output file name... configure: error: C compiler cannot create executables
On Mon, Sep 15, 2008 at 12:22 PM, Hallvard B Furuseth < h.b.furuseth@usit.uio.no> wrote:
Emmanuel Dreyfus writes:
One thing that might explain the mess, from <sys/un.h>: /*
- Socket options for UNIX IPC domain.
*/ #if defined(_NETBSD_SOURCE) #define LOCAL_CREDS 0x0001 /* pass credentials to receiver
*/
#define LOCAL_CONNWAIT 0x0002 /* connects block until accepted
*/
#endif (...) Adding a #define _NETBSD_SOURCE may help, but it can also open a can of worms.
Well, to get LOCAL_CREDS it looks like you'll have to open that can of worms. I suggest you try ./configure --enable-<everything under the sky> CPPFLAGS=_NETBSD_SOURCE and report how it works. Or if it doesn't, see if ./configure --disable-<everything under the sky> CPPFLAGS=_NETBSD_SOURCE helps, in case that helps narrow down the problems.
Should probably compile with plenty of compiler warnings (set in CFLAGS) and look for anything which didn't show up with the same warnings but without _NETBSD_SOURCE.
-- Hallvard
Hallvard B Furuseth h.b.furuseth@usit.uio.no wrote:
./configure --enable-<everything under the sky> CPPFLAGS=_NETBSD_SOURCE and report how it works. Or if it doesn't, see if
I assume you mean CPPFLAGS=-D_NETBSD_SOURCE
Emmanuel Dreyfus writes:
Hallvard B Furuseth h.b.furuseth@usit.uio.no wrote:
./configure --enable-<everything under the sky> CPPFLAGS=_NETBSD_SOURCE and report how it works. Or if it doesn't, see if
I assume you mean CPPFLAGS=-D_NETBSD_SOURCE
Whoops. Yup.
Im afraid the outcome is the exact same
netbsd# ldapsearch -x -H ldapi:// -b '' -s base -LLL supportedSASLMechanisms dn:
netbsd#
On Mon, Sep 15, 2008 at 1:12 PM, Hallvard B Furuseth < h.b.furuseth@usit.uio.no> wrote:
Emmanuel Dreyfus writes:
Hallvard B Furuseth h.b.furuseth@usit.uio.no wrote:
./configure --enable-<everything under the sky> CPPFLAGS=_NETBSD_SOURCE and report how it works. Or if it doesn't, see if
I assume you mean CPPFLAGS=-D_NETBSD_SOURCE
Whoops. Yup.
-- Hallvard
David Markey writes:
Im afraid the outcome is the exact same netbsd# ldapsearch -x -H ldapi:// -b '' -s base -LLL supportedSASLMechanisms dn:
Looking back at this path a little...
Not sure if this is needed with NetBSD, but: Is the ldapsearch you use from $PATH the same as the one you compiled with -D_NETBSD_SOURCE?
Does include/portable.h define HAVE_SYS_UN_H? If not, config.log hopefully shows why.
If yes, does LOCAL_CREDS get defined when you compile daemon.c? Try e.g. cd servers/slapd rm daemon.o make daemon.o and run the resulting compilation command without '-c -o daemon.o' and see if the LOCAL_CREDS part gets #ifdeffed out.
netbsd# /usr/bin/ldapsearch -x -H ldapi:// -b '' -s base -LLL supportedSASLMechanisms dn:
netbsd# /usr/pkg/bin/ldapsearch -x -H ldapi:// -b '' -s base -LLL supportedSASLMechanisms dn:
netbsd#
Im building from pkgsrc so my whole build tree gets downloaded everytime to everything 100% is getting compiled again.
On Mon, Sep 15, 2008 at 3:01 PM, Hallvard B Furuseth < h.b.furuseth@usit.uio.no> wrote:
David Markey writes:
Im afraid the outcome is the exact same netbsd# ldapsearch -x -H ldapi:// -b '' -s base -LLL
supportedSASLMechanisms
dn:
Looking back at this path a little...
Not sure if this is needed with NetBSD, but: Is the ldapsearch you use from $PATH the same as the one you compiled with -D_NETBSD_SOURCE?
Does include/portable.h define HAVE_SYS_UN_H? If not, config.log hopefully shows why.
If yes, does LOCAL_CREDS get defined when you compile daemon.c? Try e.g. cd servers/slapd rm daemon.o make daemon.o and run the resulting compilation command without '-c -o daemon.o' and see if the LOCAL_CREDS part gets #ifdeffed out.
-- Hallvard
Hallvard B Furuseth wrote:
David Markey writes:
Im afraid the outcome is the exact same netbsd# ldapsearch -x -H ldapi:// -b '' -s base -LLL supportedSASLMechanisms dn:
Looking back at this path a little...
Not sure if this is needed with NetBSD, but: Is the ldapsearch you use from $PATH the same as the one you compiled with -D_NETBSD_SOURCE?
Does include/portable.h define HAVE_SYS_UN_H? If not, config.log hopefully shows why.
If yes, does LOCAL_CREDS get defined when you compile daemon.c? Try e.g. cd servers/slapd rm daemon.o make daemon.o and run the resulting compilation command without '-c -o daemon.o' and see if the LOCAL_CREDS part gets #ifdeffed out.
All of that is irrelevant. There is no code in liblutil that uses LOCAL_CREDS. As I said in my first reply - if your NetBSD doesn't provide getpeereid() then you need to file an ITS to get the relevant APIs supported. None of the current substitutes in liblutil match any of what you quoted from the NetBSD docs.
Howard Chu hyc@symas.com wrote:
As I said in my first reply - if your NetBSD doesn't provide getpeereid() then you need to file an ITS to get the relevant APIs supported. None of the current substitutes in liblutil match any of what you quoted from the NetBSD docs.
Right, I have the whole story.
getpeereid(3) has been added in NetBSD-current on 2007/08/09. That feature has not yet been included in a stable release. It will be available in NetBSD-5.0.
The remaining of this message is quite off-topic, but while we are there:
Upgrading to NetBSD-current will make he feature working. Another approach would be to try patching NetBSD-4.0 to add just the required feature.
If you want to try that route, checkout latest source from the netbsd-4 branch, and try to apply the patches produced by the diff at the bottom of this commit log (you will need to hack it a bit): http://mail-index.netbsd.org/source-changes/2007/08/09/0017.html
i forgot to mention that im using current.
netbsd# uname -a NetBSD netbsd.dmarkey.com 4.99.72 NetBSD 4.99.72 (XEN3PAE_DOMU)
On Tue, Sep 16, 2008 at 12:44 PM, Emmanuel Dreyfus manu@netbsd.org wrote:
Howard Chu hyc@symas.com wrote:
As I said in my first reply - if your NetBSD doesn't provide getpeereid() then you need to file an ITS to get the relevant APIs supported. None of the current substitutes in liblutil match any of what you quoted from the NetBSD docs.
Right, I have the whole story.
getpeereid(3) has been added in NetBSD-current on 2007/08/09. That feature has not yet been included in a stable release. It will be available in NetBSD-5.0.
The remaining of this message is quite off-topic, but while we are there:
Upgrading to NetBSD-current will make he feature working. Another approach would be to try patching NetBSD-4.0 to add just the required feature.
If you want to try that route, checkout latest source from the netbsd-4 branch, and try to apply the patches produced by the diff at the bottom of this commit log (you will need to hack it a bit): http://mail-index.netbsd.org/source-changes/2007/08/09/0017.html
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu@netbsd.org
On Tue, Sep 16, 2008 at 12:58:46PM +0100, David Markey wrote:
i forgot to mention that im using current.
Then it should work.
Check that <unistd.h> indeed contains: #if defined(_NETBSD_SOURCE) (...) int getpeereid(int, uid_t *, gid_t *); (...) #endif
Check that the build you did with -D_NETBSD_SOURCE has a reference to getpeereid(3), using nm(1) command: nm `which slapd`|grep getpeereid
If it does not, then there is something wrong with the build. If it does, then you can check it is indeed called at runtime: # gdb slapd (gdb) b getpeereid (gdb) r -d0 -u slapd -h ldapi:///
Try to connect and see if you break when entering getpeereid(3).
int getpeereid(int, uid_t *, gid_t *);
is in there alright.
On Tue, Sep 16, 2008 at 1:14 PM, Emmanuel Dreyfus manu@netbsd.org wrote:
On Tue, Sep 16, 2008 at 12:58:46PM +0100, David Markey wrote:
i forgot to mention that im using current.
Then it should work.
Check that <unistd.h> indeed contains: #if defined(_NETBSD_SOURCE) (...) int getpeereid(int, uid_t *, gid_t *); (...) #endif
Check that the build you did with -D_NETBSD_SOURCE has a reference to getpeereid(3), using nm(1) command: nm `which slapd`|grep getpeereid
If it does not, then there is something wrong with the build. If it does, then you can check it is indeed called at runtime: # gdb slapd (gdb) b getpeereid (gdb) r -d0 -u slapd -h ldapi:///
Try to connect and see if you break when entering getpeereid(3).
-- Emmanuel Dreyfus manu@netbsd.org
openldap-software@openldap.org
-
David Markey -
Emmanuel Dreyfus -
Hallvard B Furuseth -
Howard Chu -
manu＠netbsd.org