#283 specify that systemd .service, .socket, .timer, … should not be marked executable
Closed: Invalid None Opened 10 years ago by zbyszek.

There's no specific policy in FPG stating that gratuitous +x is not wanted, apart from "Permissions on files must be set properly. Executables should be set with executable permissions, for example." in File Permissions. Various types of .unit files are not programs, and marking them as executable is misleading. Currently only a few packages do that [1], but it'd be nice to clarify.

Proposed wording to add to https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files:
"""
=== File mode ===
Unit files should be owned by user:group root:root, with permission mask of 0644.
"""

Once/if the packaging guidelines are amended, systemd will add an rpmlint check [2].

[1] % find /usr/lib/systemd/system/ -type f -perm -700
/usr/lib/systemd/system/tcsd.service
/usr/lib/systemd/system/openvpn@.service
/usr/lib/systemd/system/apg@.service
/usr/lib/systemd/system/ksmtuned.service
/usr/lib/systemd/system/distccd.service
/usr/lib/systemd/system/hsqldb.service
/usr/lib/systemd/system/ksm.service
/usr/lib/systemd/system/apg.socket
/usr/lib/systemd/system/wpa_supplicant.service

[2] http://cgit.freedesktop.org/systemd/systemd/tree/TODO?id=4641a16b15a0e50b61259316b3fda43e0b48f7d5#n638


Once/if the packaging guidelines are amended, systemd will add an rpmlint check

There's no need to wait for the guidelines update. The rpmlint check makes sense in any case.

IMO, the generic Debian policy on permissions should be adopted for Fedora rather than make this systemd specific

http://www.debian.org/doc/debian-policy/ch-files.html

10.9 Permissions and owners

Adding this wording is denied for the following reasons:

  • 0644 is the rpm permissions default (as is root ownership)
  • Ownership and exec perms do not prevent proper systemd operation (or open up a security issue)
  • We felt it would be redundant and inappropriate to add "files must be root:root 0644" to every domain specific guideline.

That said, we are fine with you submitting this as an rpmlint check to the rpmlint upstream.

Votes on this response (+1:7, 0:0, -1:0)

Replying to [comment:3 spot]:

Adding this wording is denied for the following reasons:

  • 0644 is the rpm permissions default (as is root ownership)

Well, what kind of an argument is this? Defaults aren't policy, are they? This was about getting this into the packaging policy!

  • Ownership and exec perms do not prevent proper systemd operation (or open up a security issue)

Oh, sure they do. Various commands that access the unit files directly don't work anymore as normal users. That's just nasty...

Also, what kind of argument is this, again? Are you suggesting that the packaging policy's job is exclusively to keep the machine from totally crashing, but nothing more?

  • We felt it would be redundant and inappropriate to add "files must be root:root 0644" to every domain specific guideline.

Well, then please do as suggested in comment #2 and add to the general guidelines that the RPM default of 0644 is not to be overriden by packages, except if they have really really good reasons to.

Reviewing the transcript of that meeting, it appears most of fpc missed my comment. I have filed a new ticket at https://fedorahosted.org/fpc/ticket/286 to document the generic guidelines. I will file a rpmlint RFE as well after the fpc vote. Hope that helps.

Oh, sure they do. Various commands that access the unit files directly
don't work anymore as normal users.

So you are saying that if the only thing that changes is that a unit file has +x "various commands" will change from working to not working? What commands? Why? Why don't you fix this? What benefit is this?

Also, what kind of argument is this, again? Are you suggesting that the
packaging policy's job is exclusively to keep the machine from totally
crashing, but nothing more?

Think of it more like the policy file is trying to teach you how to swim, there's enough information already telling you how to move your arms and legs that we don't want to have a lot of information saying "don't stab yourself in the eye with a knife" or even "you should breath air, and not breath water". In the former case because it's just junk that obscures the information people need, and the later also because there might be cases where it's better to do something "unconventional".

Replying to [comment:6 james]:

Oh, sure they do. Various commands that access the unit files directly
don't work anymore as normal users.

So you are saying that if the only thing that changes is that a unit file has +x "various commands" will change from working to not working? What commands? Why? Why don't you fix this? What benefit is this?

"Various commands" stop working when the permissions are too strict, e.g. 0700 root:root. +x is just confusing. "Various commands" are systemd diagnostic tools like systemctl, systemd-analyze, systemd-delta, and more generic things.

Also, what kind of argument is this, again? Are you suggesting that the
packaging policy's job is exclusively to keep the machine from totally
crashing, but nothing more?

Think of it more like the policy file is trying to teach you how to swim,
But packaging is not as intuitive as swimming. People use the packaging guidelines often
as a guide, not a rule-book. In principle all files could be +x without breaking anything,
but that'd be pretty ugly. Sometimes it's good to put something in writing, even if
it's inferable from general principles.

Replying to [comment:8 sundaram]:

@lennart, fpc approved a generic version

https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions
That's great, actually better then spamming the guidelines with systemd unit specific rule.

Thanks for getting this done! This is indeed better than solutions specific to the subsystem!

Now we just need rpmlint checks for this. (Also, an rpmlint check to ensure random rpms don't ship systemd preset files would be good too)

Login to comment on this ticket.

Metadata