Hi, On Do, Nov 12, 2009 at 12:33:42 +0100, Marco Skambraks wrote:

hi, On Thu, 12 Nov 2009, Halim Sahin wrote:

...

Hello, Does xineliboutput support this? The Problem: the Kids shouldn't be able to view or modify anything in the system. E. G. /media should contain all content and it shouldn't be possible to change to /.

do you mean a chroot env?

Yes.

that would be nice to set a chroot dir for the xineliboutput media-player maybe with an additional cmdline param --chroot /media

and then use the chroot param as a directory prefix for the media-player/filebrowser

thanks

marco

...

Any ideas how to do this? Regards Halim

---

vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Yes. Gruß Halim

Hi, On Do, Nov 12, 2009 at 02:41:53 +0200, Theunis Potgieter wrote:

command: chroot /my/chroot/area /usr/bin/vdr-sxfe

Create the chroot with the help of the tool ldd, ldd vdr-sxfe will tell you what shared objects vdr-sxfe requires to start. This is an interim solution until xineliboutput supports the original request.

Afaik this would run only the frontend under a chroot environment. The filebrowser of the mediaplayer runs not inside the chroot. So it doesn't restrict the filebrowser of the mediaplayer.

If you use pipe then you need to link that into your chroot environment. If you don't want to use vdr-sxfe in remote mode and rather use local frontend. Then I guess the whole vdr will have to placed into a chroot environment.

Sorry if my question was not understood currectly. I don't want to run sxfe/vdr etc under a chroot env. My concerns are about the build-in filebrowser of xineliboutput. It should be restricted to a special folder like /media. This whould avoid damages to the system :-). More ideas? BR. halim

Halim Sahin wrote:

Sorry if my question was not understood currectly. I don't want to run sxfe/vdr etc under a chroot env. My concerns are about the build-in filebrowser of xineliboutput. It should be restricted to a special folder like /media. This whould avoid damages to the system :-). More ideas?

To prevent modifying system files you should run vdr as normal user (--user=vdr). Just don't give it write access to any other places than /media (and /video ?). Of course this doesn't protect VDR config files and recordings ...

For the file browser you can try attached, untested patch. Add following line to vdr's setup.conf: xineliboutput.Media.RootDir=/media

Note that it is not bulletproof ; one can easily bypass the checks with symlinks, like ln -s / /media/root.

- Petri