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:
> [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 <email@example.com> 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)
I don't understand what this is complaining about. Obviously
MAXHOSTNAMELEN is define (see rpc/types.h) otherwise the non-hurd build
would fail. Also, I've realized adding:
#define MAXHOSTNAMELEN 64
to auth_unix.c eliminates this "error". But again those ifdefs are
not needed on "normal" builds so what gives?
> ../../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?
> ../../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’
These to are valid issues. The same code is defined in both a .c
file and a header file.
> ../../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.)
Again these are defined through sys/socket.h (actually in bits/socket.h).
So again I'm a bit confused as to what is needed...
> 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.