* CJ van den Berg <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 05, 2007 at 01:19:45PM +0200, Ed Schouten wrote:
> > * CJ van den Berg <[EMAIL PROTECTED]> wrote:
> > > On Tue, Jun 05, 2007 at 07:39:26AM +0200, Ed Schouten wrote:
> > > > When we want to support chroot(), we must open the device before the
> > > > actual chroot() call and only close the device when shutting down. This
> > > > is what the OSS module does, for example. When I look at the API of the
> > > > Simple API, there is no way to change the the pa_sample_spec afterwards.
> > >
> > > Why not just hardlink the pulseaudio socket (ie.
> > > /tmp/pulse-${USER}/native
> > > or /var/run/pulse/native) into the chroot?
> >
> > Because I'd like the application to not require any resources while
> > chroot()'ed. That's also why the application calls res_init() before the
> > chroot()-call, which causes stuff that needs DNS (AudioScrobbler, HTTP
> > audio streams) to Just Work (tm).
>
> It requires the resource (ie. the pulseaudio socket) either way. Whether it
> opens it before the chroot or after makes no difference. Either way the
> process has an open file descriptor that connects it to pulseaudio that may
> (or may not) be a security risk.Of course I'll always need the socket, but it would be cool if users wouldn't have to hardlink the socket to get music inside the chroot working. I took a look at the PulseAudio source code and it looks like it isn't possible to change the pa_sample_spec of an open stream (see stream.c). Maybe this evening I'll take a look if it's possible to delay the opening of the stream when the `ss' argument is NULL, so I can call pa_simple_new() to already instantiate the connection to the daemon before the chroot() call. Yours, -- Ed Schouten <[EMAIL PROTECTED]> WWW: http://g-rave.nl/
pgp0TopwDPlXD.pgp
Description: PGP signature
_______________________________________________ pulseaudio-discuss mailing list [email protected] https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
