service file permissions breaking due to file 5.47 / redhat-rpm-config

[Petr Sklenar]

Hi,

while testing F45 Rawhide I noticed systemd complaining during boot:

Configuration file /usr/lib/systemd/system/flatpak-add-fedora-repos.service
   is marked executable. Please remove executable permission bits.
   Proceeding anyway.

It turns out file 5.47 now classifies .service files as
application/x-wine-extension-ini instead of text/plain. This breaks
brp-mangle-shebangs, which greps for text/ to find executable files
without shebangs and chmod -x them.

So any package using install -p without explicit -m 0644 for unit
files ends up shipping them with 0755. The big ones (systemd, httpd,
nginx...) set permissions explicitly, so they are unaffected.

I couldn't find a better way to check this than downloading the RPMs
and scanning them directly, since repodata don't include file
permissions:

dnf5 download --repo=rawhide --destdir /tmp/scan/ <package-list>

for f in /tmp/scan/*.rpm; do
      rpm -qlp --dump "$f" \
      | grep -E '/usr/lib/systemd/.*.(service|socket|timer)' \
      | grep '0100755 '
  done

On an installed system it's simpler:
  find /usr/lib/systemd -type f -name '*.service' -perm /111 -ls

I scanned all 1160 packages that ship unit files in rawhide
(x86_64 + noarch) and found 20 affected:

aprsd, archlinux-keyring, asahi-battery,
   containernetworking-plugins, crossfire, flatpak,
   gnupg2 (dirmngr, gpg-agent, keyboxd), grub2-tools,
   ip-sentinel, liquidwar-server, Perlbal, restmbmaster,
   scsi-target-utils, sgx-aesm, spindown, up-imapproxy,
   vaultwarden, vsomeip3-routingmanager

Filed bugs:
   https://bugzilla.redhat.com/show_bug.cgi?id=2513643 (file)
   https://bugzilla.redhat.com/show_bug.cgi?id=2513837 (redhat-rpm-config)

Note that these packages were built during the F45 mass rebuild,
so even if file or brp-mangle-shebangs gets fixed, these 20
packages won't pick up the fix until they are rebuilt individually.

RPM developers also pointed out in BZ#2512037 that relying on
brp-mangle-shebangs for this is fragile anyway, and specs should
just use install -m 0644.

Should we file individual bugs for these 20 packages, or fix the
specs directly? Either way they'll need a rebuild. I can go ahead
and file the bugzilla tickets if that makes sense.

--
Petr Sklenar

[Adam Williamson]

On Thu, 2026-08-13 at 12:42 +0200, Petr Sklenar via devel wrote:
> RPM developers also pointed out in BZ#2512037 that relying on
> brp-mangle-shebangs for this is fragile anyway, and specs should
> just use install -m 0644.

Perhaps this should be added to
https://docs.fedoraproject.org/en-US/packaging-guidelines/Systemd/
and/or covered by fedora-review.
> Should we file individual bugs for these 20 packages, or fix the
> specs directly? Either way they'll need a rebuild. I can go ahead
> and file the bugzilla tickets if that makes sense.

I'd suggest just forwarding this email to the maintainers of the
packages first, and see how many get resolved that way. Then we could
file bugs on the remainder.

[Chris Adams]

Once upon a time, Adam Williamson  said:
> > Should we file individual bugs for these 20 packages, or fix the
> > specs directly? Either way they'll need a rebuild. I can go ahead
> > and file the bugzilla tickets if that makes sense.
>
> I'd suggest just forwarding this email to the maintainers of the
> packages first, and see how many get resolved that way. Then we could
> file bugs on the remainder.

I flagged the email in my box to get up-imapproxy. :)

[Mateus R. Costa]

Em qui., 13 de ago. de 2026, 07:42, Petr Sklenar via devel <
[e-mail]> escreveu:
> Hi,
>
> while testing F45 Rawhide I noticed systemd complaining during boot:
>
> Configuration file
> /usr/lib/systemd/system/flatpak-add-fedora-repos.service
>    is marked executable. Please remove executable permission bits.
>    Proceeding anyway.
>
> It turns out file 5.47 now classifies .service files as
> application/x-wine-extension-ini instead of text/plain. This breaks
> brp-mangle-shebangs, which greps for text/ to find executable files
> without shebangs and chmod -x them.
>
> So any package using install -p without explicit -m 0644 for unit
> files ends up shipping them with 0755. The big ones (systemd, httpd,
> nginx...) set permissions explicitly, so they are unaffected.
>
> I couldn't find a better way to check this than downloading the RPMs
> and scanning them directly, since repodata don't include file
> permissions:
>
> dnf5 download --repo=rawhide --destdir /tmp/scan/ <package-list>
>
> for f in /tmp/scan/*.rpm; do
>       rpm -qlp --dump "$f" \
>       | grep -E '/usr/lib/systemd/.*.(service|socket|timer)' \
>       | grep '0100755 '
>   done
>
> On an installed system it's simpler:
>   find /usr/lib/systemd -type f -name '*.service' -perm /111 -ls
>
> I scanned all 1160 packages that ship unit files in rawhide
> (x86_64 + noarch) and found 20 affected:
>
> aprsd, archlinux-keyring, asahi-battery,
>    containernetworking-plugins, crossfire, flatpak,
>    gnupg2 (dirmngr, gpg-agent, keyboxd), grub2-tools,
>    ip-sentinel, liquidwar-server, Perlbal, restmbmaster,
>    scsi-target-utils, sgx-aesm, spindown, up-imapproxy,
>    vaultwarden, vsomeip3-routingmanager
>
> Filed bugs:
>    https://bugzilla.redhat.com/show_bug.cgi?id=2513643 (file)
>    https://bugzilla.redhat.com/show_bug.cgi?id=2513837 (redhat-rpm-config)
>
> Note that these packages were built during the F45 mass rebuild,
> so even if file or brp-mangle-shebangs gets fixed, these 20
> packages won't pick up the fix until they are rebuilt individually.
>
> RPM developers also pointed out in BZ#2512037 that relying on
> brp-mangle-shebangs for this is fragile anyway, and specs should
> just use install -m 0644.
>
> Should we file individual bugs for these 20 packages, or fix the
> specs directly? Either way they'll need a rebuild. I can go ahead
> and file the bugzilla tickets if that makes sense.
>
> --
> Petr Sklenar
>
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://forge.fedoraproject.org/infra/tickets/issues/new

Hello all,

I have a few notes/questions about this:

* .service files are effectively based on .ini syntax, so it makes a lot of
sense they are are recognized as .ini files
* I don't get at all why it being recognized as an .ini for handling with
wine would actually warrant executable permission, what does wine try to do
with it?
* Why don't we have a mime type specific to systemd units instead of
relying on text/plain? We do know they have most characteristic of an .ini
plus having several specific extensions that are usually only used with
systemd.

Thanks for your time,
Mateus Rodrigues Costa

[Barry]

> On 13 Aug 2026, at 20:46, Mateus R. Costa  wrote:
> .service files are effectively based on .ini syntax, so it makes a lot of sense they are are recognized as .ini files

I think you are conflating the syntax of a files content with the semantics of a files content.

In which case .services files are not .ini files right?

Barry

[Mateus R. Costa]

Em qui., 13 de ago. de 2026, 18:08, Barry  escreveu:
> > On 13 Aug 2026, at 20:46, Mateus R. Costa
>
> wrote:
> > .service files are effectively based on .ini syntax, so it makes a lot
>
> of sense they are are recognized as .ini files
>
> I think you are conflating the syntax of a files content with the
> semantics of a files content.
>
> In which case .services files are not .ini files right?
>
> Barry
>
> --
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it:
> https://forge.fedoraproject.org/infra/tickets/issues/new

Sure, but think about it this way:
A .ini file is a specific type of a plain text file.
A systemd unit file is a ini-like file.

Depending on how the mime type detection logic runs it makes a lot of sense
that eventually a systemd unit file gets detected as a ini.

So why not estabilish a "systemd unit file mime type" for specifically this
scenario instead of relying on the plain text mime type now that we know
the possibility of this problem?

Thanks for your time,
Mateus Rodrigues Costa

[Nicolas Mailhot]

Le jeudi 13 août 2026 à 18:54 -0300, Mateus R. Costa a écrit :
>

Hi,
> > In which case .services files are not .ini files right?

They are .ini files. However :
1. wine has no business owning ini files they are not Windows-specific
2. making config files executable by default is completely insane

that screams wack-a-mole engineering where one just disables every
protection to help broken software work

[David Tardon]

Hi,

On Fri, 2026-08-14 at 09:21 +0200, Nicolas Mailhot via devel wrote:
> Le jeudi 13 août 2026 à 18:54 -0300, Mateus R. Costa a écrit :
> > > In which case .services files are not .ini files right?
>
> They are .ini files. However :
> wine has no business owning ini files they are not Windows-
>
> specific

This. INI is just a configuration format. Yes, it was originally used
on Windows, by the OS itself and by various applications. But that
doesn't make it Windows-exclusive. INI-like configuration formats have
been used for various things on Linux for ~25 years (.desktop files, D-
Bus services, git config, etc.). Any tool that makes that assumption
needs to be fixed--it's not 1996 anymore.

Whether a separate MIME type for systemd units should be created is
completely orthogonal to the issue.

D.

[Jelle van der Waa]

On 13/08/2026 12:42, Petr Sklenar via devel wrote:
> Hi,
>
> while testing F45 Rawhide I noticed systemd complaining during boot:
> Configuration file /usr/lib/systemd/system/flatpak-add-fedora-repos.service
> is marked executable. Please remove executable permission bits.
> Proceeding anyway.
>
> It turns out file 5.47 now classifies .service files as
> application/x-wine-extension-ini instead of text/plain. This breaks
> brp-mangle-shebangs, which greps for text/ to find executable files
> without shebangs and chmod -x them.

I tested file 5.48 on Arch Linux and it didn't have this issue. The 
unpushed Fedora update to 5.48 also doesn't have this issue, but was 
blocked on a different issue. [1]

[root@fedora-rawhide-127-0-0-2-2201 ~]# file --mime-type /tmp/test.service
/tmp/test.service: text/plain
[root@fedora-rawhide-127-0-0-2-2201 ~]# rpm -qa file
file-5.48-1.fc45.x86_64

[1] https://bodhi.fedoraproject.org/updates/FEDORA-2026-412ea7bd7b

[Lennart Poettering]

On Do, 13.08.26 12:42, Fedora Development ML ([e-mail]) wrote:
> Hi,
>
> while testing F45 Rawhide I noticed systemd complaining during boot:
>
> Configuration file /usr/lib/systemd/system/flatpak-add-fedora-repos.service
>    is marked executable. Please remove executable permission bits.
>    Proceeding anyway.
>
> It turns out file 5.47 now classifies .service files as
> application/x-wine-extension-ini instead of text/plain. This breaks
> brp-mangle-shebangs, which greps for text/ to find executable files
> without shebangs and chmod -x them.

This sounds highly problematic, and really should be reverted.

But even if they keep it, they should really not do this for such
files that have UNIX line endings rather than windows ones, i.e. CRLF
vs. LF.

Lennart

--
Lennart Poettering, Berlin

[Steve Grubb]

On Sunday, August 16, 2026 3:26:05 AM Eastern Daylight Time Lennart 
Poettering wrote:
> On Do, 13.08.26 12:42, Fedora Development ML
> ([e-mail]) wrote:
> > while testing F45 Rawhide I noticed systemd complaining during boot:
> >    Configuration file
> >    /usr/lib/systemd/system/flatpak-add-fedora-repos.service
> > is marked executable. Please remove executable permission bits.
> > Proceeding anyway.
> >
> > It turns out file 5.47 now classifies .service files as
> > application/x-wine-extension-ini instead of text/plain. This breaks
> > brp-mangle-shebangs, which greps for text/ to find executable files
> > without shebangs and chmod -x them.
>
> This sounds highly problematic, and really should be reverted.

This was so problematic that it was reverted in commit f37cc42c on March 25, 
2026, explicitly because it “matches too many unix stanza files.”

What appears to have happened, is commit 7a1ada9c landed Sept 6,2025. 
File-5.47 was released Feb 27. Complaints and it was reverted in March as 
noted. Then June 8, 2026 file 5.48 was released. If we just update to the 
latest, this problem goes away.

-Steve

[Gary Buhrmaster]

On Sun, Aug 16, 2026 at 3:45 PM Steve Grubb via devel
 wrote:
> On Sunday, August 16, 2026 3:26:05 AM Eastern Daylight Time Lennart
> Poettering wrote:
> > This sounds highly problematic, and really should be reverted.
>
> This was so problematic that it was reverted in commit f37cc42c on March 25,
> 2026, explicitly because it “matches too many unix stanza files.”
>
> What appears to have happened, is commit 7a1ada9c landed Sept 6,2025.
> File-5.47 was released Feb 27. Complaints and it was reverted in March as
> noted. Then June 8, 2026 file 5.48 was released. If we just update to the
> latest, this problem goes away.
>
> -Steve

The update to 5.48 was submitted around a month
ago, but it failed a fedora functional gating test
in bodhi.  As I recall, it is waiting on the packager
(and/or upstream) to address the issue.

[Steve Grubb]

On Sunday, August 16, 2026 1:05:29 PM Eastern Daylight Time Gary Buhrmaster 
wrote:
> On Sun, Aug 16, 2026 at 3:45 PM Steve Grubb via devel
>  wrote:
> > On Sunday, August 16, 2026 3:26:05 AM Eastern Daylight Time Lennart
> > Poettering wrote:
> > > This sounds highly problematic, and really should be reverted.
> >
> > This was so problematic that it was reverted in commit f37cc42c on March
> > 25, 2026, explicitly because it “matches too many unix stanza files.”
> >
> > What appears to have happened, is commit 7a1ada9c landed Sept 6,2025.
> > File-5.47 was released Feb 27. Complaints and it was reverted in March
> > as noted. Then June 8, 2026 file 5.48 was released. If we just update to
> > the latest, this problem goes away.
>
> The update to 5.48 was submitted around a month
> ago, but it failed a fedora functional gating test
> in bodhi.  As I recall, it is waiting on the packager
> (and/or upstream) to address the issue.

I suppose commit f37cc42c could be applied while the gating blocker is being 
worked out. I also see some issues in upstream for which I'm sending patches.

-Steve

[Chris Adams]

Once upon a time, Steve Grubb  said:
> On Sunday, August 16, 2026 1:05:29 PM Eastern Daylight Time Gary Buhrmaster 
> wrote:
> > On Sun, Aug 16, 2026 at 3:45 PM Steve Grubb via devel
> >  wrote:
> > > On Sunday, August 16, 2026 3:26:05 AM Eastern Daylight Time Lennart
> > > Poettering wrote:
> > > > This sounds highly problematic, and really should be reverted.
> > >
> > > This was so problematic that it was reverted in commit f37cc42c on March
> > > 25, 2026, explicitly because it “matches too many unix stanza files.”
> > >
> > > What appears to have happened, is commit 7a1ada9c landed Sept 6,2025.
> > > File-5.47 was released Feb 27. Complaints and it was reverted in March
> > > as noted. Then June 8, 2026 file 5.48 was released. If we just update to
> > > the latest, this problem goes away.
> >
> > The update to 5.48 was submitted around a month
> > ago, but it failed a fedora functional gating test
> > in bodhi.  As I recall, it is waiting on the packager
> > (and/or upstream) to address the issue.
>
> I suppose commit f37cc42c could be applied while the gating blocker is being 
> worked out. I also see some issues in upstream for which I'm sending patches.

Still wouldn't hurt to depend on packaging behavior to install proper
perms.  I checked up-imapproxy, it was using "install -m 0755" for no
good reason, so I fixed it in rawhide.

[Panu Matilainen]

On 8/16/26 8:44 PM, Chris Adams wrote:
> Once upon a time, Steve Grubb  said:
> > On Sunday, August 16, 2026 1:05:29 PM Eastern Daylight Time Gary Buhrmaster
> > wrote:
> > > On Sun, Aug 16, 2026 at 3:45 PM Steve Grubb via devel
> > >  wrote:
> > > > On Sunday, August 16, 2026 3:26:05 AM Eastern Daylight Time Lennart
> > > > Poettering wrote:
> > > > > This sounds highly problematic, and really should be reverted.
> > > >
> > > > This was so problematic that it was reverted in commit f37cc42c on March
> > > > 25, 2026, explicitly because it “matches too many unix stanza files.”
> > > >
> > > > What appears to have happened, is commit 7a1ada9c landed Sept 6,2025.
> > > > File-5.47 was released Feb 27. Complaints and it was reverted in March
> > > > as noted. Then June 8, 2026 file 5.48 was released. If we just update to
> > > > the latest, this problem goes away.
> > >
> > > The update to 5.48 was submitted around a month
> > > ago, but it failed a fedora functional gating test
> > > in bodhi.  As I recall, it is waiting on the packager
> > > (and/or upstream) to address the issue.
> >
> > I suppose commit f37cc42c could be applied while the gating blocker is being
> > worked out. I also see some issues in upstream for which I'm sending patches.
>
> Still wouldn't hurt to depend on packaging behavior to install proper
> perms.  I checked up-imapproxy, it was using "install -m 0755" for no
> good reason, so I fixed it in rawhide.

Thanks. THIS is the main thing to do here.

Installing files with explicit 0755 permissions and then expecting 
something getting packaged is ... peculiar.

- Panu -

[Panu Matilainen]

On 8/17/26 11:01 AM, Panu Matilainen wrote:
> On 8/16/26 8:44 PM, Chris Adams wrote:
> > Once upon a time, Steve Grubb  said:
> > > On Sunday, August 16, 2026 1:05:29 PM Eastern Daylight Time Gary 
> > > Buhrmaster
> > > wrote:
> > > > On Sun, Aug 16, 2026 at 3:45 PM Steve Grubb via devel
> > > >  wrote:
> > > > > On Sunday, August 16, 2026 3:26:05 AM Eastern Daylight Time Lennart
> > > > > Poettering wrote:
> > > > > > This sounds highly problematic, and really should be reverted.
> > > > >
> > > > > This was so problematic that it was reverted in commit f37cc42c on 
> > > > > March
> > > > > 25, 2026, explicitly because it “matches too many unix stanza files.”
> > > > >
> > > > > What appears to have happened, is commit 7a1ada9c landed Sept 6,2025.
> > > > > File-5.47 was released Feb 27. Complaints and it was reverted in March
> > > > > as noted. Then June 8, 2026 file 5.48 was released. If we just 
> > > > > update to
> > > > > the latest, this problem goes away.
> > > >
> > > > The update to 5.48 was submitted around a month
> > > > ago, but it failed a fedora functional gating test
> > > > in bodhi.  As I recall, it is waiting on the packager
> > > > (and/or upstream) to address the issue.
> > >
> > > I suppose commit f37cc42c could be applied while the gating blocker 
> > > is being
> > > worked out. I also see some issues in upstream for which I'm sending 
> > > patches.
> >
> > Still wouldn't hurt to depend on packaging behavior to install proper
> > perms.  I checked up-imapproxy, it was using "install -m 0755" for no
> > good reason, so I fixed it in rawhide.
>
> Thanks. THIS is the main thing to do here.

Argh, it's Monday alright.
> Installing files with explicit 0755 permissions and then expecting 
> something getting packaged is ... peculiar.

"expecting something else getting packaged" is what it should say.

- Panu -
> - Panu -