Re: [Libtirpc-devel] Fwd: Re: proposed patch to rpcbind to providefiner-grained security controls than offered by the -i option

[Steve Dickson <SteveD at redhat dot com>]

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 <thomas@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)
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:
    #ifndef MAXHOSTNAMELEN
    #define MAXHOSTNAMELEN 64
    #endif
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...

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