Chmod elastic-agent.service to 0644 so we avoid systemd log spam

[rdner]

Describe the enhancement:

Our customers who installed Elastic-Agent as a systemd service are experiencing logs spam:

Mar 25 16:00:02 <host.name> systemd: Configuration file /etc/systemd/system/elastic-agent.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.

A bit more context on the issue:

• A user asked about this exact warning in the systemd repo in Github Configuration file X is marked world-inaccessible spam systemd/systemd#770
• An issue on the Red Hat bug tracker https://bugzilla.redhat.com/show_bug.cgi?id=1241565

It seems that the resolution would be to chmod the elastic-agent.service file to 0644 instead of 0600.

We're already setting it right for *.service files created for Beats.

https://github.com/elastic/elastic-agent/blame/adef7f74d879f900e19f851624c9da3d6755a29a/dev-tools/packaging/packages.yml#L60-L62

Describe a specific use case for the enhancement or feature:

Installing Elastic Agent as a systemd service on Linux.

What is the definition of done?

In all Linux packaging the elastic-agent.service file has 0644 permissions.

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[blakerouse]

How was this Elastic Agent installed? RPM or install command?

[rdner]

@blakerouse it was installed via RPM on Red Hat Enterprise Linux release 8.9.

[blakerouse]

Looking at the packaging it seems that it has permissions set to 0644 - https://github.com/elastic/elastic-agent/blob/main/dev-tools/packaging/packages.yml#L62

Are you sure this was from a RPM install? I would expected the install command to more than likely do the wrong thing, as this clearly has it setting it to 0644 which you highlighted in the description.

[rdner]

@blakerouse is not the line you linked for each Beat though?

I thought the file path lib/systemd/system/{{.BeatServiceName}}.service: is used for each Beat service, e.g. Filebeat. Or it's for the agent itself?

[blakerouse]

@blakerouse is not the line you linked for each Beat though?

I thought the file path lib/systemd/system/{{.BeatServiceName}}.service: is used for each Beat service, e.g. Filebeat. Or it's for the agent itself?

You are linking it from the elastic-agent repo so this is for the Elastic Agent itself, the elastic-agent repo doesn't install any beats service files.

[rdner]

@blakerouse Correction: the customer didn't use the RPM package to install the agent, it was installed from .tar.gz using the elastic-agent install command.

[blakerouse]

Okay then this makes sense.

[blakerouse]

Filed upstream kardianos/service#395

[blakerouse]

Upstream fix kardianos/service#397

[ycombinator]

Resolved via elastic/go-service#2.

[blakerouse]

I was reading this completely wrong the error message says world-inaccessible I was reading that as world-accessible. So the issue is not in the github.com/kardianos/service, as it clearly writes the file with 0644.

I am unable to find a place in the Elastic Agent where install is writing that file with 0600, which is actually what is being complained about in the error log.

Looking at the DEB/RPM install path it is also set to 0644. https://github.com/elastic/elastic-agent/blob/main/dev-tools/packaging/packages.yml#L62

Based on this I am wondering if the issue is actually specific to this one host, as we have not had any others report this issue. No code paths seem to match how this would occur.

[jlind23]

Based on this I am wondering if the issue is actually specific to this one host, as we have not had any others report this issue. No code paths seem to match how this would occur.

If this happened exclusively on this host and hasn't been reported since then shall we really keep this issue open?

[ycombinator]

I lean towards closing this issue but perhaps we should do a quick sanity check first of the actual behavior: install Agent on Red Hat Enterprise Linux Server release 7.9 (Maipo) and Red Hat Enterprise Linux release 8.9 (Ootpa) and check that the /etc/systemd/system/elastic-agent.service file is actually created with 0644. If that's the case, then there's nothing to fix so we can close this issue.

[blakerouse]

I did a test on RedHat 8.10 and the service file is correct.

[blake_rouse@blake-redhat-8 ~]$ sudo ls -lh /usr/lib/systemd/system/elastic-agent.service
-rw-r--r--. 1 root root 802 Jun 11 07:13 /usr/lib/systemd/system/elastic-agent.service

I did another test on RedHat 9.4 and the service file is correct.

[blake_rouse@blakerouse-redhat-9 ~]$ ls -lh /usr/lib/systemd/system/elastic-agent.service
-rw-r--r--. 1 root root 802 Jun 11 07:13 /usr/lib/systemd/system/elastic-agent.service

I am going to close this issue as I am unable to reproduce.