Invokes unlinkat() with relative path, leaks files

[larsch]

Steps to reproduce:

1. Run influxd (passively fails to delete files, which are leaked). unlinkat() returns ENOENT
2. Run influxd as non-root user with working directory set to /root (fails to delete files and gives up on some operations). unlinkat() return EROFS.

Expected behaviour:

influxd should use absolute path names to delete files, so that they are deleted as intended.

Actual behaviour:

influxd uses a relative path when trying to delete a file and this fails, causing the files to leak, and influxd to give up on certain operations if the current working directory is read only to the user running influxd.

When working directory is not writable, this call fails with EROFS. The strace for this looks like (when working directory is not owned by user running influxdb).

unlinkat(6542, "MANIFEST1938224951", 0) = -1 EROFS

This appears to be interpreted by influxdb as if the database directory is on a read-only file system (it is not), and it will refuse writes to the bucket.

When running as root, or when setting the working directory to some directory that is writeable by the user account running influxdb, unlinkat instead returns ENOENT:

unlinkat(AT_FDCWD, "MANIFEST4269701056", 0) = -1 ENOENT

This is probably still an error, since the file was intended to be deleted. The path given is relative and does not exist.

The influxdb binary does not appear to change the working directory.

Environment info:

OS: Arch Linux
Version: influxdb-2.7.5-1 (Package by Arch)
Linux 6.7.4-arch1-1 x86_64

Additional info:

The EROFS error happens when running influxd under system with the systemd as a separater user (e.g. influxdb:influxdb) without setting the WorkingDirectory in the service file. This leads to the influxd process running with working directory set to /root, which is unwritable (read-only) to the process.

I checked the /proc/PID/cwd for the running influxd, and it had /root as the working directory, so it does not appear to change directory when deleting the file. Hence I think using relative paths must be the error. This error is undetected when the working directory is writable since unlinkat returns ENOENT.

Setting working directory in the service file to /var/lib/influxdb is a workaround against the hard failure (preventing writing to buckets), but the instance is probably still leaking files in the filesystem since they are not being deleted.

[Service]
WorkingDirectory=/var/lib/influxdb