Re: Connect to Unix domain socket instead of host:port

[Gary E. Miller]

Yo Pinnacle!

On Thu, 19 Dec 2024 17:51:21 -0500
Pinnacle Systems Group <pinnaclesystemsgroup@gmail.com> wrote:

> It’s not immediately clear to me—perhaps you have additional insight
> into the guy’s host and network setup—what “host” he’s on or how his
> host connected to the local network.

Nope.  I have no additional insight.  All I know is what your have
seen in the email thred.

> Given this uncertainty, and considering cgpsd isn’t inherently
> designed with robust security in mind, isn't it prudent to disable
> the default TCP listener and use a UNIX domain socket instead? The
> idea here is an ounce of prevention is worth a pound of cure...

Once again, no.

> Disabled TCP approach offers several significant security and
> performance advantages:
> 
> 1. Enhanced Security
> 
> TCP sockets are accessible over the network, making them a potential
> target for unauthorized access or exploitation.

Uh, no.  As long as  you do not use the -G option, only localhost
has TCP access.

> On the other hand, UNIX domain sockets are confined to the local
> system, and access can be tightly controlled through userland file
> permissions, ensuring only authorized users or processes can connect.

Do you really acre that other local users can't find your lat/lon?  If
so, don't run gpsd on that host.

And disabling TCP access still allows local access over SHM and d-bus.

> 2. Reduced Overhead and Faster
> 
> TCP communication involves network stack processing, which can
> introduce latency and consume additional system resources.

gpsd has been benchmakred many times.  The overwhelming hog in gpsd
is the parser.  Dwarfing all other CPU use combined.

> UNIX domain sockets bypass the network stack, allowing faster and more
> efficient local inter-process communication.

Yes, but unmeasureably small in gpsd's case.

> 3. Simplified Access Control
> 
> With UNIX domain sockets, access permissions can be managed using
> filesystem ACLs, making it straightforward to define which users or
> groups have access to gpsd.

You still have the SHM iand d-busaccess.  And if you do not trust your
local users then you should not run gpsd on that host.

> 4. No Network Dependency
> 
> Using a UNIX domain socket eliminates reliance on network interfaces,
> reducing the risk of issues caused by network misconfigurations or
> outages.

Prettty rare to have localhost misconfigured.  I'll take that risk.

> For example, in a setup like gpsd -F /path/to/gpsd.sock, clients
> connect to the specified socket path instead of a TCP port.

And a lot easier to type wring than simply: cgps

> It’s important to ensure that file permissions on the socket are
> properly configured to allow client access without compromising
> security.

We are going in circles.  Other users can still access via SHM and
d-bus, and if your lat/lon is a secret then you should not have other
users.

> This configuration is generally a more secure and efficient option,
> especially when network exposure isn’t required. Let me know if this
> aligns with what you’ve seen or if there’s any additional context I
> should consider!

Once aggin.  No.

>  UNIX domain sockets are confined to the local machine and can be
> secured with appropriate file permissions in the userland of his host.

Once again, yes, but gpsd is still accessible other ways.

> Additionally, UNIX domain sockets can offer performance benefits by
> reducing network stack overhead, leading to more efficient
> inter-process communication on the same host.

Once again, no.

> Therefore, in scenarios where gpsd does not require remote network
> access, (and whether or not he "trust" his host machine)  configuring
> it to use UNIX domain sockets is a prudent choice to enhance security
> and efficiency.

Once again, no.

> Do you disagree?

Once again, yes.

Can we stop going around in circles now?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin