OSS in jail

[Konstantin Belousov]

On Sun, Dec 13, 2015 at 08:23:57AM -0700, James Gritton wrote:
> On 2015-12-12 15:44, Lu??s Fernando Schultz Xavier da Silveira wrote:
> > 
> > I would like one of my jails to have the ability to play back sound,
> > but not to record it. As I understand, sound is played back by writing
> > to /dev/dsp and recorded by reading from it. Hence, placing the 
> > /dev/dsp
> > device (and /dev/dsp[0-9]* devices) in the jail via devfs.rules is not
> > a solution since the jail superuser can override permissions on these
> > devices and even read from them when they lack read permission.
> > 
> > Is there a way to give a device to a jail in write-only mode?
> > If not, is it possible to create a virtual OSS stack and give that to
> > the jail?
> > How would you solve this problem?
> > 
> > Also, is it possible to give the jail a mixer device that can only read
> > mixer settings but not alter them?
> 
> There is no mechanism for adding a device to a jail with partial 
> permissions.  Generally, it wouldn't just be reading and writing, but a 
> per-device decision on different ioctl calls.  This would require an 
> entire jail device framework that doesn't exist.
> 
> I suppose it's possible to create a virtual OSS stack - sounds like a 
> pretty big project though.  If I had this job to do, that's likely the 
> direction I'd go, though instead of a virtual OSS driver, I'd consider 
> something on the user level, with a listening UNIX socket inside the 
> jail.  I doubt this would work seamlessly without recompiling software 
> though (again, the ioctl question).

There is a lot of usermode sound servers, already written, some of them
are even used. I am sure that among the dozens there are several which
would allow to restrict access and provide connector into the jail.

IMO it is much more practical way to achieve the stated goal than try
to restrict /dev/dsp access.