[vdr] examining debian's vdr patchset

Udo Richter udo_richter at gmx.de
Thu Jun 30 19:27:21 CEST 2005


C.Y.M wrote:
> -    setMax(minsize[colorid].y2, yp + len - 1);
> +    setMax(minsize[colorid].y2, yp);

This looks like a minor performance bug fix, as the written area is a
horizontal line, not a box.

> +static bool OsdMatchesArea(cOsd *osd, tArea &area)

This (plus remainings of patch) re-allocates the osd if the new area
doesnt fit into the old osd. This may be a bug, if this actually occurs.

As far as I understand it, the dvbspu.c translates subpictures to osd
bitmaps, though I dont really know who actually uses this. Maybe DVD plugin?



The second patch is a security patch, described here:
http://www.debian.org/security/2005/dsa-656

> -           FILE *f = fopen(FileName, "wb");
> +           int fd = open(FileName, O_CREAT | O_EXCL | O_TRUNC | O_RDWR, 00640);
> +           if (fd > -1) {
> +           FILE *f = fdopen(fd, "wb");

This seems to force creating a new GRAB file with (00640 & ~umask)
access rights, while fopen always uses (00666 & ~umask).
Additionally, this version fails if the GRAB file already exists.
(vdradmin-am wont work with this, as the file is pre-allocated by
vdradmin-am. ;) )

I dont agree with this fix, because (1) insecure SVDRP access is IMHO a
security hole in any case, (2) if VDR runs properly as restricted user,
there shouldnt be any critical files with write access, and (3) though
the patched version cannot overwrite existing files, it still can create
new files anywhere, and thats IMHO not much better.

Cheers,

Udo



More information about the vdr mailing list