Created attachment 2094833 [details]
File: description

Created attachment 2094834 [details]
File: os_info

aannoaanno, thanks for reporting this. I wonder why pasta(1) is trying to write to that file at all in your setup. How are you running pasta? Is it started by Podman, Docker, stand-alone? How does the command line look like?

(In reply to aannoaanno from comment #0)
> Description of problem:
> SELinux is preventing pasta from 'append' accesses on the Datei /home/tpasch/.config/Code/logs/20250623T121301/window1/exthost/extHostTelemetry.log.

Assuming that this denial isn't causing any problems, it's probably a good thing that SELinux is blocking access to this file from pasta. If this is a common issue, we can probably add a `dontaudit` rule for this (again, assuming that this denial isn't causing any problems).

(In reply to Stefano Brivio from comment #3)
> I wonder why pasta(1) is
> trying to write to that file at all in your setup. How are you running
> pasta? Is it started by Podman, Docker, stand-alone? How does the command
> line look like?

Wild guess: a VSCode extension is starting a Podman container, and the extension has redirected the logs to this file. In this case, probably the easiest way to find the command line would be to run

    pgrep 'pasta|podman' | xargs -n1 pstree -aTls

*** Bug 2375740 has been marked as a duplicate of this bug. ***

I'm not 100% sure what has triggered the problem. But I've used vs code for dev containers development (and I have configured vs code to use podman instead of docker).

Hence Max Chernoff might be right: I have used an extension (dev containers) that is start a podman container. Not sure if this involves redirecting podman logs, though.

Ok, I found some similar error messages in my logs, and I'm able to reproduce it by simply running any container from the built-in VSCode terminal:

    $ podman run --pull=newer -it --rm docker.io/library/ busybox:latest /bin/sleep 5

    $ journalctl --no-hostname --follow --lines=0 _AUDIT_TYPE=1400
    Oct 27 03:43:59 audit[450988]: AVC avc:  denied  { append } for  pid=450988 comm="pasta" path="/home/max/.config/Code/logs/20251026T232449/ptyhost.log" dev="nvme0n1p3" ino=15430938 scontext=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:config_home_t:s0 tclass=file permissive=0

I'm pretty sure that the source of the problem is that VSCode doesn't properly close its file descriptors in the terminal (which gave me problems a few weeks ago with bubblewrap):

    $ ls -l /proc/$$/fd
    total 0
    lrwx------. 1 max max 64 Oct 27 03:44 0 -> /dev/pts/0
    lrwx------. 1 max max 64 Oct 27 03:44 1 -> /dev/pts/0
    lr-x------. 1 max max 64 Oct 27 03:44 103 -> /usr/share/code/v8_context_snapshot.bin
    lrwx------. 1 max max 64 Oct 27 03:44 2 -> /dev/pts/0
    lrwx------. 1 max max 64 Oct 27 03:44 255 -> /dev/pts/0
    lr-x------. 1 max max 64 Oct 27 03:44 34 -> anon_inode:inotify
    lrwx------. 1 max max 64 Oct 27 03:44 36 -> 'socket:[3053407]'
    l-wx------. 1 max max 64 Oct 27 03:44 42 -> /home/max/.config/Code/logs/20251026T232449/ptyhost.log
    lrwx------. 1 max max 64 Oct 27 03:44 43 -> 'socket:[3098537]'

I'm not really sure why pasta is trying to write to fd42, but I think that VSCode not closing its file descriptors on exec is the bigger issue. It looks like that that's already been reported upstream

    https://github.com/microsoft/vscode/issues/258187

so I'm not sure if there's anything else that pasta should do here.

pasta was already patched to close all fds on startup that it doesn't need so I really don't get how they end up being accessed by pasta at all. Does selinux log the denials just if the fd is being leaked even if the process never tries to use them and closes them instead?

A simpler reproducer which doesn't require the vscode terminal:
podman run --rm  quay.io/libpod/testimage:20241011 sleep 100 10<~/Documents # (or pick any other file or directory that pasta is not allowed to use)

I am still getting a denied here even though I am sure pasta never tries to read from fd 10 and just closes it and then later open a socket in its place when I check /proc/<pid>/fd of the pasta process.

avc:  denied  { read } for  pid=13573 comm="pasta" path="/home/pholzing/Documents" dev="dm-0" ino=285 scontext=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir permissive=0

> Does selinux log the denials just if the fd is being leaked even if the process never tries to use them and closes them instead?

It appears yes. Running the following script

    cat <<- 'EOF' > close-fds.c
    	#define _GNU_SOURCE
    	#include <limits.h>
    	#include <linux/close_range.h>
    	#include <stdio.h>
    	#include <unistd.h>

    	int main() {
    		if (!close_range(STDERR_FILENO + 1, UINT_MAX, 0)) {
    			puts("success");
    			return 0;
    		} else {
    			perror("failure");
    			return 1;
    		}
    	}
    EOF

    gcc -Wall -Wextra -Wpedantic close-fds.c -o close-fds

    chcon --user=system_u --role=object_r --type=local_test_exec_t --range=s0-s0 ./close-fds

    cat <<- 'EOF' > close-fds.cil
    	;; Includes
    	(roleattributeset cil_gen_require object_r     )
    	(roleattributeset cil_gen_require unconfined_r )
    	(typeattributeset cil_gen_require domain       )
    	(typeattributeset cil_gen_require fs_t         )
    	(typeattributeset cil_gen_require unconfined_t )
    	(typeattributeset cil_gen_require user_devpts_t)

    	;; Define the new types
    	(type     local_test_exec_t         )
    	(roletype object_r local_test_exec_t)

    	(type     local_test_t             )
    	(roletype unconfined_r local_test_t)

    	;; Set the type attributes
    	(typeattributeset entry_type (local_test_exec_t))
    	(typeattributeset exec_type  (local_test_exec_t))
    	(typeattributeset file_type  (local_test_exec_t))

    	(typeattributeset domain (local_test_t))

    	;; Allow relabelling of files to local_test_exec_t
    	(allow unconfined_t      local_test_exec_t (file       (getattr relabelto setattr)))
    	(allow local_test_exec_t fs_t              (filesystem (associate                )))

    	;; Allow transition to local_test_exec_t
    	(typetransition domain       local_test_exec_t process local_test_t)
    	(allow          local_test_t local_test_exec_t (file (entrypoint)))

    	;; Minimum rules required for execution
    	(allow local_test_t local_test_exec_t (file     (map               )))
    	(allow local_test_t local_test_exec_t (file     (execute read      )))
    	(allow local_test_t user_devpts_t     (chr_file (getattr read write)))
    EOF

    sudo semodule --install=./close-fds.cil

    journalctl --no-hostname --follow --lines=0 _AUDIT_TYPE=1400 &

    ./close-fds 4</etc/passwd 5>/tmp/close-fds.out

gives me the following output:

    Nov 04 01:32:29 audit[167477]: AVC avc:  denied  { read } for  pid=167477 comm="close-fds" path="/etc/passwd" dev="nvme1n1p3" ino=62345 scontext=unconfined_u:unconfined_r:local_test_t:s0-s0:c0.c1023 tcontext=system_u:object_r:passwd_file_t:s0 tclass=file permissive=0
    Nov 04 01:32:29 audit[167477]: AVC avc:  denied  { write } for  pid=167477 comm="close-fds" path="/tmp/close-fds.out" dev="tmpfs" ino=24512 scontext=unconfined_u:unconfined_r:local_test_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0
    success

Which seems like a SELinux bug to me, but maybe this is working as intended? 

Anyways, I guess this means that there isn't anything that pasta can do here to make these AVC messages stop appearing.

> Which seems like a SELinux bug to me, but maybe this is working as intended? 

I think it is working as intended. A online search shows this blog from Dan: https://danwalsh.livejournal.com/53603.html

> When SELinux blocks the leaked file descriptor you usually end up with a strange looking AVC about the new domain trying to read or write a random file or a socket owned by the parent or even worse an ancestor.


> Anyways, I guess this means that there isn't anything that pasta can do here to make these AVC messages stop appearing.

Agree so this can be closed as not a bug, this must be fixed at the root cause in the process who is leaking fds for no reason.