OSS in jail

[Luís Fernando Schultz Xavier da Silveira]

I see. I does indeed seem a sound server is the appropriate solution.

Thanks.

On Sun, Dec 13, 2015 at 06:05:22PM +0200, Konstantin Belousov wrote:
> 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.
> _______________________________________________
> freebsd-jail at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-jail
> To unsubscribe, send any mail to "freebsd-jail-unsubscribe at freebsd.org"
>