Password-less access for operating system users, anonymous read-only TCP access

[bijwaard]

Dear all,
Thanks for this great real-time database, we use it to store sensor measurements on IoT devices in the field, that don't have permanent Internet access, and make the measurements available by tunneling/proxying the 8086 port to act as influx datasource for grafana and for queries via command-line or python scripts. Influxdb offers great possibilities for fine-grained authorization, we would additionally love the possibility for an easy setup without maintenance of credentials that can easily be made read-only to avoid (remote) tampering.

To this end it would be great when users of the operating system that are in the influxdb group can access influx as admin without having to log in. This could e.g. be supported by adding an IPC port (i.e. read-write for the influxdb group), that supports the same HTTP interface as TCP port 8086 does. All clients (e.g. the ones using an influxdb_client library) can then choose to use the IPC or TCP port (or fallback to TCP/IPC when the other is not available). Such an IPC port could look like ipc:///tmp/influx_port and would by default be readable/writable by the influxdb user and group. On Linux systems additional users could be made admin by adding them to the influxdb group in /etc/group, I expect something similar to be available on other systems.

Once this IPC port exists, it would be great to have an option in the influxdb configuration file to make the TCP port read-only for anonymous access, i.e. only support read queries on databases without having to setup credentials.

I can think of the following advantages for password-less access on same machine:

• the influx command-line on the same machine will be usable without a password for OS users in the influxdb group, other users would still be able to use influxdb credentials over the TCP port.
• services like telegraph, python scripts or golang programs that use the influxdb_client library on the same machine don't need to to hard-code their password in configuration files
• it would provide a way to recover lost admin credentials that are used over TCP via a user in influxdb group
• it would reduce the burden of creating & maintaining influxd credentials on a multitude of IoT devices

I can think of the following advantages for anonymous read-only access over TCP:

• this won't give dangerous write access by default when tunneling/proxy the TCP port, i.e. reduce the risk for remote attacks that inject/overwrite/delete data
• not necessary to setup/maintain credentials on every IoT device for e.g. grafana datasources and other remote queries
• remote admin/write access over TCP would still be possible by adding the required credentials

Kind regards,
Dennis Bijwaard

[bijwaard]

We have been using influxdb 1.8 until now and really like the effortless setup for reading/writing to the database locally, but dislike that everyone can write remotely by default. When considering migration to influxdb 2.x, we would be forced to create and maintain a multitude of credentials on all IoT devices and apparently will no longer be able to use 32bit IoT devices. Blocking based on private addresses does not seem to help when port-forwarding of port 8086 is used through ssh, since the remote ssh client would still use local addresses.

Hence local read/write access through an alternative local connection (IPC or some other local socket) would be great to offer local read/write access for e.g. users in the influxdb group (/etc/group) and additionally deny remote write access by default on port 8086 (unless user authentication is enabled in /etc/influxdb/influxdb.conf). Moreover, it will reduce the burden to maintain a multitude of credentials locally on influxdb level and in configuration files, for e.g. telegraf and local sensors, and remotely for influxdb datasources in grafana, etc..

[bijwaard]

Looks like a unix-socket, which communicates via a file in the filesystem (that can have read/write access for the influxdb group), would be easiest for the local connection, and most of the httpd functionality can probably be re-used. I found a simple golang example to use HTTP communication over a unix-socket in https://gist.github.com/ulfurinn/45d94d8bcc99e0a10025. The main change for the server-side would be to listen to another type of socket: listener, err := net.Listen("unix", "http.sock"), the main change for the client side would be to use another transport that connects to the unix socket.

Apparently, there is already support for unix sockets build in influxdb.services.httpd.Service.NewService(), now the question is how to listen to both the TCP port and the unix socket and grant R/W to the unix socket and only read access to the TCP port.

[bijwaard]

Got the build-in unix socket working after some struggles in influxdb 1.8.

The default /var/run/influxdb.sock does not work since most linux distributions have /var/run only writable for root (#24343). It worked after creating a /var/run/influxdb folder owned by and writable for influxdb and configuring the socket as /var/run/influxdb/influxdb.sock, see influxd.conf:

  # Enable http service over unix domain socket
  # unix-socket-enabled = false
  unix-socket-enabled = true
  # The path of the unix domain socket.
  bind-socket = "/var/run/influxdb/influxdb.sock"

After starting influxd with the socket, the influx cli can be run to connect with the socket:
influx -socket /var/run/influxdb/influxdb.sock

When authentication is enabled in the configuration, currently user and password is required both via the socket and via the TCP port 8086. If that can be changed by e.g. using a different configured handler over the socket connection, that would be very helpful.