Bug 2171377

Summary: rpmlint does not follow FPG guidelines regarding file permissions
Product: [Fedora] Fedora Reporter: Zdenek Dohnal <zdohnal>
Component: rpmlintAssignee: Tom "spot" Callaway <spotrh>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 39CC: j, spotrh, tmz, twoerner
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-11-27 21:05:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Zdenek Dohnal 2023-02-20 08:34:00 UTC
Description of problem:
If package has an executable which has to be run by a specific user to work, rpmlint reports an error:

$ rpmlint results_braille-printer-app/2.0b0^386eea385f/1.fc39/braille-printer-app-2.0b0^386eea385f-1.fc39.x86_64.rpm 
=========================================================================================================== rpmlint session starts ===========================================================================================================
rpmlint: 2.4.0
configuration:
    /usr/lib/python3.10/site-packages/rpmlint/configdefaults.toml
    /etc/xdg/rpmlint/fedora-legacy-licenses.toml
    /etc/xdg/rpmlint/fedora-spdx-licenses.toml
    /etc/xdg/rpmlint/fedora.toml
    /etc/xdg/rpmlint/scoring.toml
    /etc/xdg/rpmlint/users-groups.toml
    /etc/xdg/rpmlint/warn-on-functions.toml
checks: 31, packages: 1

braille-printer-app.x86_64: E: non-standard-executable-perm /usr/lib/cups/backend/cups-brf 744
============================================================================ 1 packages and 0 specfiles checked; 1 errors, 0 warnings, 1 badness; has taken 0.1 s ============================================================================

The Fedora Packaging Guidelines says about file permissions (https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_permissions):

"
Inside of /usr, files should be owned by root:root unless a more specific user or group is needed for security. They MUST be universally readable (and executable if appropriate).
"

which tells us not having a binary universally executable is not against FPG as rpmlint says.

I understand sometimes this issue happens when the project/packager doesn't set the permissions incorrectly in scenarios where the binary should be executable universally, but it may block reviews of packages which have binaries which really can't be run by a different user than owner (f.e. the backend in braille-printer-app package has to be started as root, because it switches to a regular user to be able to write printing output into a file in its home directory)

Version-Release number of selected component (if applicable):
rpmlint-2.4.0-4.fc38.noarch

How reproducible:
always

Steps to Reproduce:
1. $ rpmlint braille-printer-app-2.0b0^386eea385f-1.fc39.x86_64.rpm

Actual results:
rpmlint returns error for file permissions

Expected results:
rpmlint returns warning

Additional info:
This was found out during braille-printer-app review process at https://bugzilla.redhat.com/show_bug.cgi?id=2169277

Comment 1 Todd Zullinger 2023-02-20 15:53:53 UTC
This seems like an issue which would be best handled via a local override, i.e.: a braille-printer-app.rpmlintrc file which included something like:

# cupsd starts the backend as root and cups-brf itself switches to the user who
# issued printing, so it needs root privileges to switch into user. The backend
# is not meant to be read, be written to by or executed by other user than
# root, so these non-standard permissions are OK.
addFilter("[EW]: non-standard-executable-perm /usr/lib/cups/backend/cups-brf 700$")

Whether it's an error or a warning, it would still be flagged in a package review, wouldn't it?  And in either case, a filter would be desirable, I think.

Changing it from Error to Warning would require patching upstream, as I don't think this is configurable (but I could be wrong).  I don't know if that would be reasonable to upstream or not.  I'd want to be able to justify it before even submitting such a patch.  But I'm not sure I can do that now.  What makes this much more suited to a warning than an error?

Comment 2 Zdenek Dohnal 2023-02-20 16:29:19 UTC
IMO you checked an incorrect part of the review - in the end I don't mind that a binary with permissions 700 is reported as error, because it is said in FPG that all files must be readable if not explained otherwise - in such case a filter is the option.

However what I find problematic is the fact rpmlint reports permission set to 744 as an error, which conflicts with packaging guidelines. I took rpmlint as an automatic tool for checking whether my package complies with packaging guidelines in certain aspects which can be checked automatically, so I thought rpmlint follows FPG. But I understand keep all RPM based distro guidelines in sync and implemented in rpmlint would be difficult...

  (In reply to Todd Zullinger from comment #1)
> Whether it's an error or a warning, it would still be flagged in a package
> review, wouldn't it?  And in either case, a filter would be desirable, I
> think.

Making it a warning (for permissions 744) could indicate that something in package could be adjusted if it makes sense, but it doesn't conflict with guidelines.

> 
> Changing it from Error to Warning would require patching upstream, as I
> don't think this is configurable (but I could be wrong).  I don't know if
> that would be reasonable to upstream or not.  I'd want to be able to justify
> it before even submitting such a patch.  But I'm not sure I can do that now.
> What makes this much more suited to a warning than an error?

IMHO because permissions 744 comply with FPG, so it is confusing to get it as an error, which implies conflict with FPG.

In case the switch can't be done, I'm okay with updating documentation with explaining 744 complies with FPG, f.e. here https://fedoraproject.org/wiki/Common_Rpmlint_issues .

Comment 3 Fedora Release Engineering 2023-08-16 07:07:24 UTC
This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.

Comment 4 Aoife Moloney 2024-11-08 10:46:49 UTC
This message is a reminder that Fedora Linux 39 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '39'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 39 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 5 Aoife Moloney 2024-11-27 21:05:14 UTC
Fedora Linux 39 entered end-of-life (EOL) status on 2024-11-26.

Fedora Linux 39 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.