[MPlayer-dev-eng] [RFC] Playlist permission model

Roberto Togni rxt at rtogni.it
Sat Feb 23 15:36:30 CET 2008


Hi all,
 this patch is a proposal to implement a permission model for playlists.

The model groups the url recognized by MPlayer in 3 categories: local
(files, file://, and probably also local network disks like smb://),
network (http://, mms://, rtsp, ...) and special (dvd://, tv://, ...).

The permission matrix is (playlist type on rows, destination url on
columns)

        | local | network | special
--------+-------+---------+---------
local   |  Ok   |   Ok    |   Ok
--------+-------+---------+---------
network |  No   |   Ok    |   No
--------+-------+---------+---------
special |  --   |   --    |   --

eg. a dvd:// url on a playlist read from a http:// stream is rejected,
a rtsp:// url from a ftp:// stream is allowed.

I don't expect to read playlists from special sources.
Relative file paths are always permitted, since they're prefixed with
the path or url of the playlist.

The permission checks are implemented after the playlist is parsed, in
the piece of code that is used to prefix the playlist url (or path) to
relative entries. If an entry is absoulte, and the url type is
incompatible with the playlist source url, the entry is removed.

The url prefix <==> url group association is defined in the stream_info
block, adding a new field src_type. This patch add the field only to
some stream modules for testing purposes, it will be added to all
streams in the final version.

The play_tree_add_bfp() in parse_embedded_playlist() is a bugfix and
will be committed separately; with the current code a file with a
relative path in an embedded playlist is prefixed with the path of the
root playlist instead of the path of the embedded playlist.
This fix is needed by this permission patch to avoid some problems in
the case of a network playlist invoked from a local playlist.

Still missing: some extra checks for windows paths (\), mov-embedded
playlists (btw they are probably broken with demuxer lavf as default).

A different approach is to create a wrapper function for
play_tree_add_file() and do the check there, preventing a file to be
added to the playtree if the permissions are wrong. Then replace all
occurrences of play_tree_add_file() in the playlist parsing code with
the new function.

Comments welcome about the permission model and alternative
implementation strategies.

Ciao,
 Roberto

-- 
Better is the enemy of good enough.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: plperm.diff
Type: text/x-patch
Size: 7131 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20080223/38369709/attachment.bin>


More information about the MPlayer-dev-eng mailing list