Bug 1933690

I think this is closely related to the linked upstream issue.

Software development generally means playing with code that is not trusted. Anyone doing software development should probably add a developer supplemental group to their account and then a rule can be created so that developer accounts can run things in the home dir. This is documented in github README.md.

allow perm=any gid=developer : ftype=%languages dir=/home

Hi Steve,

This doesn't work, I added your proposed rule as first rule and still get the deny:

$ id
uid=1000(myuser) gid=1000(myuser) groups=1000(myuser),1001(developer) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

$ git init
fatal: cannot copy '/usr/share/git-core/templates/hooks/fsmonitor-watchman.sample' to '/home/myuser/.git/hooks/fsmonitor-watchman.sample': Operation not permitted


This is because /usr/share/git-core/templates/hooks/fsmonitor-watchman.sample cannot be opened at all, as shown by strace:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
6623  07:33:12.049381 openat(AT_FDCWD, "/usr/share/git-core/templates/hooks/fsmonitor-watchman.sample", O_RDONLY) = -1 EPERM (Operation not permitted) <0.000623>
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Fapolicyd needs very careful tweaking if it's used in a build server or developer's system. This is because by their very nature are creating software which sometimes involves running newly created programs which are certainly not in the trust database. Fapolicyd is better suited to a less volatile environment where applications that run are in the trust database.

This can be solved by modifying the configuration. The rule in comment #2 works. The retest failure reported in comment #3 was not in /home. Regarding git files in /usr/share/git-core/templates, these files are language files that do not follow language specific naming conventions. 
$fapolicyd-cli --ftype /usr/share/git-core/templates/hooks/fsmonitor-watchman.sample
text/x-perl

This causes them to get missed during rpm installation and they do not windup in the trust database. 

$ fapolicyd-cli --dump | grep fsmonitor-watchman.sample
$

There are two approaches, add them to the file trust db manually:

$ fapolicyd-cli --file add /usr/share/git-core/templates

The only drawback is the file trust db will need to be refreshed whenever git is updated.

$ fapolicyd-cli --file update /usr/share/git-core/templates

The second approach is to add another rule allowing developer gid to access /usr/share/git-core/templates.

In almost any situation, problems like this can be worked around by configuration changes. There are troubleshooting steps that need to be done to find a solution.

1) run in debug mode and see what the objection is. Which rule number made the decision?
2) run faplicyd-cli --list to see what that rule number is.
3) Is there a rule above it that should have allowed access? If so, did the trust not match? Verify the file's mime type.
4) Is the file in the trust database? If not add it or a directory in the path that contains it.
5) If you need a big loophole for a kind of user, make rules for their access.

Go the trust route first. Only add rules if the trust situation is volatile and unweildy.

Git can be enabled with a filter file. On 9.3/8.9: /etc/fapolicyd/fapolicyd-filter.conf can be set so git files won't be excluded from trust DB. On 9.2/8.8 it's /etc/fapolicyd/rpm-filter.conf.

I just added "+ git-core" there:

[root@Axis fapolicyd]# cat fapolicyd-filter.conf
# default filter file for fedora

+ /
 - usr/include/
 - usr/share/
  + git-core/
  # Python byte code
  + *.py?
  # Python text files
  + *.py
  # Some apps have a private libexec
  + */libexec/*
  # Ruby
  + *.rb
  # Perl
  + *.pl
  # System tap
  + *.stp
  # Javascript
  + *.js
  # Java archive 
  + *.jar
  # M4
  + *.m4
  # PHP
  + *.php
  # Perl Modules
  + *.pm
  # Lua
  + *.lua
  # Java
  + *.class
  # Typescript
  + *.ts
  # Typescript JSX
  + *.tsx
  # Lisp
  + *.el
  # Compiled Lisp
  + *.elc
 - usr/src/kernel*/
  + */scripts/*
  + */tools/objtool/*

As per comment 8 and 9, can we close this bugzilla since git can be enabled later by administrator?

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days