Created attachment 2094665 [details]
File: description

Created attachment 2094666 [details]
File: os_info

This should be resolved by proper labeling the directories/files, or moving them to expected place.

Same issue in my Fedora 43 when I run VS Code with Cline plugin and GitHub MCP server that works in podman.

$ podman images
REPOSITORY                        TAG         IMAGE ID      CREATED     SIZE
ghcr.io/github/github-mcp-server  latest      def612fe2c72  6 days ago  36.5 MB

Following is the error that I receive from SELinux:

SELinux is preventing pasta from append access on the file /home/rosti/.config/Code/logs/20251124T112047/window1/exthost/GitHub.copilot/GitHub Copilot.log.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that pasta should be allowed append access on the GitHub Copilot.log file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'pasta' --raw | audit2allow -M my-pasta
# semodule -X 300 -i my-pasta.pp

Additional Information:
Source Context                unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023
Target Context                unconfined_u:object_r:config_home_t:s0
Target Objects                /home/rosti/.config/Code/logs/20251124T112047/wind
                              ow1/exthost/GitHub.copilot/GitHub Copilot.log [
                              file ]
Source                        pasta
Source Path                   pasta
Port                          <Unknown>
Host                          fedora
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-42.16-1.fc43.noarch
Local Policy RPM              
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     fedora
Platform                      Linux fedora 6.17.8-300.fc43.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Fri Nov 14 01:47:12 UTC 2025
                              x86_64
Alert Count                   32
First Seen                    2025-11-24 11:17:11 IST
Last Seen                     2025-11-24 11:20:59 IST
Local ID                      67607003-4fd6-4ddb-bab5-b171ddcd7d49

Raw Audit Messages
type=AVC msg=audit(1763976059.923:368): avc:  denied  { append } for  pid=26009 comm="pasta" path=2F686F6D652F726F7374692F2E636F6E6669672F436F64652F6C6F67732F3230323531313234543131323034372F77696E646F77312F657874686F73742F4769744875622E636F70696C6F742F47697448756220436F70696C6F742E6C6F67 dev="dm-0" ino=7272073 scontext=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=file permissive=0


Hash: pasta,pasta_t,config_home_t,file,append

config_home_t is not the right label for a system service to work with.
Assign the proper label or move files to expected place.

Hi Zdenek,

(In reply to Zdenek Pytela from comment #5)
> config_home_t is not the right label for a system service to work with.
> Assign the proper label or move files to expected place.

Thanks for the analysis. As an end-user, I haven't manually assigned these labels; they are generated automatically by the tooling I am using.

I am using VS Code with the Cline plugin, which has an option to install the GitHub MCP server on Podman. The original reporter likely used a similar setup where a VS Code plugin interacts with Podman.

Could you advise which upstream project we should report this to (VS Code, Cline, or the GitHub MCP Server)?

Also, could you clarify what the proper label should be in this context, or where these files are expected to be located for a system service to access them?

I think the right type is var_log_t as these are log files and setting it silenced these type of alerts for me.  

chcon -R -t var_log_t ~/.config/Code/logs

As for what's causing it, it's kinda a combination of the default SELinux policy and how vscode handles logs.

The SELinux policy applies config_home_t type to ~/.config files which is correct. Applications should not be writing logs to config_home_t types. But due to vscode creating ~/.config/Code/logs for logs but generating the correct type label, it errors out.

imo, the end all solution needs to come from vscode generating or coming with a policy to set the correct folder policy (or moving logs to a correct logs path). Not sure if a policy could be added to Fedora to handle this in the meantime.