userland process rpc.lockd opens untraceable ports...is something wrong here?

[Ben Woods]

On Wed, 20 Feb 2019 at 11:03 pm, Ian Lepore <ian at freebsd.org> wrote:

> On Wed, 2019-02-20 at 07:02 -0700, BBlister wrote:
> > # sockstat | grep -E '874|815'
> > ?        ?          ?     ?  tcp4   *:815                 *:*
> > ?        ?          ?     ?  tcp6   *:874                 *:*
> >
> > rpcinfo -p reports just one port
> > # rpcinfo -p| grep -E '874|815'
> >     100021    0   tcp    815  nlockmgr
> >     100021    1   tcp    815  nlockmgr
> >     100021    3   tcp    815  nlockmgr
> >     100021    4   tcp    815  nlockmgr
> >
>
> The situation here is that the socket is neither opened by nor owned by
> any userland process. The rpc.lockd implementation is split into a
> kernel piece and a userland piece, and much of the work is done in-
> kernel. The in-kernel part of the code contacts the userland daemon
> part for help when it needs to.
>
> So the socket is created by the in-kernel part of lockd, and it is not
> tied to any file descriptor. Tools which report on userland processes
> use file descriptors to associate kernel resources with the processes
> that own them. In this case, it is the kernel itself that owns the
> socket, so it can't be reported as belonging to any userland process.
>
> If you're interested in poking around in the code involved, see
> nlm_server_main() in src/sys/nlm/nlm_prot_impl.c
>
> -- Ian



A similar issue is discussed in this bug report:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212608

My personal opinion is that this is confusing and worrying for users, and a
better user experience would be if sockstat and lsof were able to detail
the owner of these open ports (either just “kernel” or better yet which
part of the kernel).

I have no idea if this is technically possible or how complicated it is. Is
anyone able to comment on this?

Regards,
Ben
-- 

--
From: Benjamin Woods
woodsb02 at gmail.com