Re: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option
On 12/15/2010 05:09 PM, Samuel Thibault wrote: Steve Dickson, le Wed 15 Dec 2010 15:48:38 -0500, a écrit : Building it with ``make -k'': ../../master/src/auth_unix.c:187: error: ‘MAXHOSTNAMELEN’ undeclared (first use in this function) I don't understand what this is complaining about. Obviously MAXHOSTNAMELEN is define (see rpc/types.h) otherwise the non-hurd build would fail. MAXHOSTNAMELEN is defined on some OSes, but not on others, as POSIX says it's an optional macro (it's not defined when there is no limitation). See http://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_MAX_PATH_tt_MAXPATHL The link to Neil's xgethostname() (http://ftp.walfield.org/pub/people/neal/xgethostname/) is broken... So I googled around and found http://walfield.org/pub/people/neal/xgethostname/xgethostname-20020413.tar.gz I'm assuming that's latest and greatest version. Also, I've realized adding: #ifndef MAXHOSTNAMELEN #define MAXHOSTNAMELEN 64 #endif to auth_unix.c eliminates this error. That's a crude way, but yes it should work. Looking around in the glibc code I see this in a number of places: /* As per RFC 1034 and 1035 a host name cannot exceed 255 octets in length. */ #ifdef MAXHOSTNAMELEN # undef MAXHOSTNAMELEN #endif #define MAXHOSTNAMELEN 256 Is this a less crude way of correcting the error? But again those ifdefs are not needed on normal builds so what gives? They are not needed on OSes which have a hostname lenght limitation, but they are needed on OSes which don't. ../../master/src/bindresvport.c:189: error: ‘IPV6_PORTRANGE’ undeclared (first use in this function) ../../master/src/bindresvport.c:190: error: ‘IPV6_PORTRANGE_LOW’ undeclared (first use in this function) This is true but these defines are in non-Linux code so I guess the hurd builds defines both Linux and non-Linux parts of the code? It just means that these are not Linux-only. But that doesn't mean it's standard macros. And indeed, while some other IPV6_* macros are in posix, IPV6_PORTRANGE* are not, and thus aren't standard. Ok... I'll just locally define them... tia, steved. -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d0a4737.6080...@redhat.com
Re: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option
Hallo! [Hurd people: this is about removing SUN RPC code from glibc, and use libtirpc instead.] On Tue, Dec 14, 2010 at 01:14:23PM -0500, Ulrich Drepper wrote: On Tue, Dec 14, 2010 at 11:26, Thomas Schwinge tho...@schwinge.name wrote: To clarify: did you have anything specific in mind? I don't know why we would want to diverge? The divergence would be there is Hurd doesn't use libtirpc. If Hurd does or will use libtirpc then there is no reason to diverge. I don't see any fundamental problems, so OK from my side, and we'll fix issues as they occur. In fact, I just had a look at git://git.infradead.org/~steved/libtirpc.git's master branch. (That's the correct one to use, right?) It has very few specifc dependencies on Linux. These should be analyzed, and probably handled differently. ./src/bindresvport.c:#ifdef __linux__ ./src/clnt_dg.c:#include linux/errqueue.h ./src/svc_auth_gss.c: /* ANDROS: change for debugging linux kernel version... Building it with ``make -k'': ../../master/src/auth_unix.c:187: error: ‘MAXHOSTNAMELEN’ undeclared (first use in this function) ../../master/src/bindresvport.c:189: error: ‘IPV6_PORTRANGE’ undeclared (first use in this function) ../../master/src/bindresvport.c:190: error: ‘IPV6_PORTRANGE_LOW’ undeclared (first use in this function) ../../master/src/clnt_bcast.c:77:1: warning: POLLRDNORM redefined In file included from /usr/include/sys/poll.h:26, from ../../master/src/clnt_bcast.c:52: /usr/include/bits/poll.h:32:1: warning: this is the location of the previous definition ../../master/src/clnt_bcast.c:78:1: warning: POLLRDBAND redefined /usr/include/bits/poll.h:33:1: warning: this is the location of the previous definition ../../master/src/clnt_vc.c:73:1: warning: SCM_CREDS redefined In file included from /usr/include/sys/socket.h:40, from ../../master/src/clnt_vc.c:55: /usr/include/bits/socket.h:261:1: warning: this is the location of the previous definition ../../master/src/clnt_vc.c:82: error: redefinition of ‘struct cmsgcred’ ../../master/src/rpc_soc.c: In function ‘clnt_com_create’: ../../master/src/rpc_soc.c:108: error: ‘SOCK_CLOEXEC’ undeclared (first use in this function) ../../master/src/rpc_soc.c:108: error: (Each undeclared identifier is reported only once ../../master/src/rpc_soc.c:108: error: for each function it appears in.) That one is in my court -- I already have patches for SOCK_CLOEXEC et al. for many months... ../../master/src/getpeereid.c: In function ‘getpeereid’: ../../master/src/getpeereid.c:39: error: storage size of ‘uc’ isn’t known ../../master/src/getpeereid.c:44: error: ‘SO_PEERCRED’ undeclared (first use in this function) ../../master/src/getpeereid.c:44: error: (Each undeclared identifier is reported only once ../../master/src/getpeereid.c:44: error: for each function it appears in.) ../../master/src/getpeereid.c:39: warning: unused variable ‘uc’ All these seem fixable without too much effort, or we can resort to disabling features we don't support yet. Do we have sombody volunteer for working on that? (Please follow up on the Hurd lists only.) Also, if libtirpc people (or anybody else) are interested in a shell account for a GNU/Hurd system, please see http://www.gnu.org/software/hurd/public_hurd_boxen.html or simply talk to me. Grüße, Thomas signature.asc Description: Digital signature
Re: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option
On 12/14/2010 04:34 PM, Ulrich Drepper wrote: On Tue, Dec 14, 2010 at 16:32, Thomas Schwinge tho...@schwinge.name wrote: [Hurd people: this is about removing SUN RPC code from glibc, and use libtirpc instead.] No, it is not. It is about making the sunrpc code unavailable for new programs but keep it around for binary compatibility. +1 steved. -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d07e6bb.4010...@redhat.com
Re: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to provide finer-grained security controls than offered by the -i option
On 12/14/2010 04:32 PM, Thomas Schwinge wrote: Hallo! [Hurd people: this is about removing SUN RPC code from glibc, and use libtirpc instead.] On Tue, Dec 14, 2010 at 01:14:23PM -0500, Ulrich Drepper wrote: On Tue, Dec 14, 2010 at 11:26, Thomas Schwinge tho...@schwinge.name wrote: To clarify: did you have anything specific in mind? I don't know why we would want to diverge? The divergence would be there is Hurd doesn't use libtirpc. If Hurd does or will use libtirpc then there is no reason to diverge. I don't see any fundamental problems, so OK from my side, and we'll fix issues as they occur. In fact, I just had a look at git://git.infradead.org/~steved/libtirpc.git's master branch. (That's the correct one to use, right?) Right... It has very few specifc dependencies on Linux. These should be analyzed, and probably handled differently. ./src/bindresvport.c:#ifdef __linux__ ./src/clnt_dg.c:#include linux/errqueue.h ./src/svc_auth_gss.c: /* ANDROS: change for debugging linux kernel version... Thanks... We will take a look... Building it with ``make -k'': ../../master/src/auth_unix.c:187: error: ‘MAXHOSTNAMELEN’ undeclared (first use in this function) ../../master/src/bindresvport.c:189: error: ‘IPV6_PORTRANGE’ undeclared (first use in this function) ../../master/src/bindresvport.c:190: error: ‘IPV6_PORTRANGE_LOW’ undeclared (first use in this function) ../../master/src/clnt_bcast.c:77:1: warning: POLLRDNORM redefined In file included from /usr/include/sys/poll.h:26, from ../../master/src/clnt_bcast.c:52: /usr/include/bits/poll.h:32:1: warning: this is the location of the previous definition ../../master/src/clnt_bcast.c:78:1: warning: POLLRDBAND redefined /usr/include/bits/poll.h:33:1: warning: this is the location of the previous definition ../../master/src/clnt_vc.c:73:1: warning: SCM_CREDS redefined In file included from /usr/include/sys/socket.h:40, from ../../master/src/clnt_vc.c:55: /usr/include/bits/socket.h:261:1: warning: this is the location of the previous definition ../../master/src/clnt_vc.c:82: error: redefinition of ‘struct cmsgcred’ ../../master/src/rpc_soc.c: In function ‘clnt_com_create’: ../../master/src/rpc_soc.c:108: error: ‘SOCK_CLOEXEC’ undeclared (first use in this function) ../../master/src/rpc_soc.c:108: error: (Each undeclared identifier is reported only once ../../master/src/rpc_soc.c:108: error: for each function it appears in.) I don't see these errors I use the following commands to build without any warnings or errors: git clone git://git.infradead.org/~steved/libtirpc.git cd libtirpc sh autogen.sh ./configure make -j8 What are you going got generate these errors? steved. That one is in my court -- I already have patches for SOCK_CLOEXEC et al. for many months... ../../master/src/getpeereid.c: In function ‘getpeereid’: ../../master/src/getpeereid.c:39: error: storage size of ‘uc’ isn’t known ../../master/src/getpeereid.c:44: error: ‘SO_PEERCRED’ undeclared (first use in this function) ../../master/src/getpeereid.c:44: error: (Each undeclared identifier is reported only once ../../master/src/getpeereid.c:44: error: for each function it appears in.) ../../master/src/getpeereid.c:39: warning: unused variable ‘uc’ All these seem fixable without too much effort, or we can resort to disabling features we don't support yet. Do we have sombody volunteer for working on that? (Please follow up on the Hurd lists only.) Also, if libtirpc people (or anybody else) are interested in a shell account for a GNU/Hurd system, please see http://www.gnu.org/software/hurd/public_hurd_boxen.html or simply talk to me. Grüße, Thomas -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d07e6ab.9050...@redhat.com
