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:Oh, good point. I missed what was going on in that example.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.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? -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson