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@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?

-- 
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