On Tue, May 28, 2024 at 10:12:56AM +0200, Stefano
Brivio wrote:
On Tue, 28 May 2024 16:55:55 +1000
David Gibson <david(a)gibson.dropbear.id.au> wrote:
On Sun, May 26, 2024 at 06:28:42PM -0400, Derek
Schrock wrote:
> Allow access to user_devpts.
>
> $ pasta --version
> pasta 0^20240510.g7288448-1.fc40.x86_64
> ...
> $ awk '' < /dev/null
> $ pasta --version
> $
>
> While this might be a awk bug it appears pasta should still have access
> to devpts.
Derek, thanks for the patch!
It's not clear to me why pasta would need
any access to /dev/pts. The
shell that pasta spawns does, of course, but it should already live in
a difference security context.
Note that that doesn't happen in a shell pasta spawned: pasta --version
doesn't do that.
Oh, good point. I missed what was going on in that example.
It's just that after that awk comamnd,
enabling access to
user_tty_device_t doesn't seem to be enough anymore, we need
user_devpts_t then. Which is probably something reasonable to enable
anyway.
Hmmm.. this still doesn't make sense to me. AFAIK, /dev/pts is about
managing pseudo-ttys, I see no reason we'd need to do that. Our
stdout *could* be a pseudo-tty, I suppose. But surely selinux can't
be requiring us to explicitly allow for any possible stdout/stderr
target? Especially not one as completely routine as a pseudo-tty -
that will be the case for anything run in an xterm.
I also can't fathom why running awk would change anything. Could
there be something bogus in the selinux profile of the original shell
which allows the awk invocation to change the context somehow?