[vlc-devel] [PATCH 1/2] dvdnav: Limit user information about insufficient permissions

[Rémi Denis-Courmont]

Hi,

I think everybody understood that the first time. I don't see how that answers my questions though.

Le 1 mai 2020 23:41:35 GMT+03:00, David Fuhrmann <david.fuhrmann at gmail.com> a écrit :
>Hello,
>
>Let me rephrase the problem:
>
>macOS Catalina can refuse access to device nodes (/dev/xxx), which is a
>new security feature. Technically, this results in open() returning
>with EPERM (specifically).
>
>This problem can be fixed if the user goes to the OS wide security
>settings and allows access for VLC. This setting is a bit hidden, and
>therefore it is mandatory here to inform the user about that in a user
>visible popup.
>
>Additionally, for good UI experience, this message shall not be shown
>for any other failure, because obviously, then the problem can not be
>fixed anymore by just going to the specific security page and enabling
>a checkbox.
>
>And most importantly, the message MUST not be shown in case there is
>just a normal probing of a normal directory or file, which might not be
>even a DVD folder or DVD ISO at all. This module seems to have a quite
>high priority and therefore it is mandatory to restrict this as much as
>possible.
>
>All of that is achieved in this patch.
>If anyone has concrete answers on my two questions I asked previously,
>or knows a better way how to achieve the same end result, feedback is
>welcome.
>
>BR. David
>
>> Am 01.05.2020 um 18:33 schrieb Rémi Denis-Courmont <remi at remlab.net>:
>> 
>> Le perjantaina 1. toukokuuta 2020, 17.20.48 EEST David Fuhrmann a
>écrit :
>>>> Am 01.05.2020 um 15:43 schrieb Rémi Denis-Courmont
><remi at remlab.net>:
>>>> 
>>>> Le perjantaina 1. toukokuuta 2020, 13.58.21 EEST
>david.fuhrmann at gmail.com
>>>> <mailto:david.fuhrmann at gmail.com> a> 
>>>> écrit :
>>>>> From: David Fuhrmann <dfuhrmann at videolan.org>
>>>>> 
>>>>> The mentioned security setting is only relevant for accessing
>>>>> RAW block devices (/dev/xxx), which is one of the main use cases
>>>>> for this module (accessing an optical drive).
>>>>> It is not relevant for file or folder access.
>>>>> 
>>>>> Therefore limit the dialog to only show it in this case.
>>>>> dvdnav does not provide a way to get the underlying error back
>>>>> to this module, therefore the path is probed again to ensure
>>>>> that the actual failure was EPERM.
>>>>> ---
>>>>> modules/access/dvdnav.c | 21 +++++++++++++++++----
>>>>> 1 file changed, 17 insertions(+), 4 deletions(-)
>>>>> 
>>>>> diff --git a/modules/access/dvdnav.c b/modules/access/dvdnav.c
>>>>> index f082f1021b..558103eae3 100644
>>>>> --- a/modules/access/dvdnav.c
>>>>> +++ b/modules/access/dvdnav.c
>>>>> @@ -377,10 +377,23 @@ static int AccessDemuxOpen ( vlc_object_t
>*p_this )
>>>>> 
>>>>>        msg_Warn( p_demux, "cannot open DVD (%s)", psz_file);
>>>>> 
>>>>> #ifdef __APPLE__
>>>>> -        vlc_dialog_display_error( p_demux, _("Problem accessing a
>system
>>>>> resource"), -            _("Potentially, macOS blocks access to
>your
>>>>> disc.
>>>>> "
>>>>> -              "Please open \"System Preferences\" -> \"Security &
>>>>> Privacy\" " -              "and allow VLC to access your external
>media
>>>>> in \"Files and Folders\" section."));
>>>>> +        /* This is only relevant when accessing
>>>>> RAW block devices */
>>>>> +        if( forced && !strncasecmp( psz_file,
>>>>> "/dev/", 5) )
>>>> 
>>>> That's a very dubious way to identify device nodes.
>>> 
>>> A better way in theory is to open() and stat() the path to check if
>this is
>>> a block device. But this does not work because the open() syscall is
>>> already rejected by the OS in this case, as seen in the next lines.
>> 
>> I don't follow the logic here. So you cannot open the device node,
>and?
>> 
>>> Does anybody knows another different way to check if a path is a
>device
>>> node, without opening the file?
>>>>> +        {
>>>>> +            int fd = vlc_open( psz_file, O_RDONLY | O_NONBLOCK );
>>>>> +            bool permissionError = ( fd == -1 && errno == EPERM
>);
>>>>> +            if( fd != -1 )
>>>>> +                vlc_close( fd );
>>>> 
>>>> And this reinvents access for no obvious reasons.
>>> 
>>> I think I tried to explain the reasons in the commit message.
>> 
>> Where? It just implies that the device node cannot be opened.
>> 
>> -- 
>> レミ・デニ-クールモン
>> http://www.remlab.net/
>> 
>> 
>> 
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel
>
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20200501/61353931/attachment.html>