Re: Connection to PVA server fails despite server

["Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>]

On Nov 10, 2020, at 5:53 PM, Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> wrote:

On 11/10/20 11:29 AM, Wlodek, Jakub wrote:

When I connected to the container from the outside, it appeared that the `softioc` name was not retained, only the uid and gid,
and I got a prompt like this:

I have no name!@xf17bm-ioc2:/$

You probably need to do something with /etc/passwd.

The libCom osiGetUserName() implementation for posix targets that Kay pointed out is basically a wrapper around getpwuid(getuid()) with appropriate checks for the result, so we’re already relying on the C library to do that for us.

If there is no name available for the process's uid, what user name should the client code send the server? This matters if the server has access security enabled, although the user-name can be easily spoofed – the other input to the access rules is the IP address of the client which is much harder for the client to spoof.

I’m going to guess that the CA server doesn’t care if no user name is provided, but the PVA server isn’t handling that like it probably should (or it’s been taught to never talk to an anonymous client).

There are several obvious approaches for fixing this: Modify the server to accept anonymous clients; change osiGetUserName() to stringify the number returned by getuid() so that gets passed to the server as the name; or have the client send some other string such as “nobody”.

I don’t think it should be fixed in osiGetUserName() itself since that’s a low-level API and should be able to tell its caller that there is no user-name associated with this process. Sending out uid numbers could be considered a security hole in some places, so longer-term I think this would have to be fixed inside the pvAccess module one way or another, not in libCom.

- Andrew

-- 

Complexity comes for free, simplicity you have to work for.