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

David Fuhrmann david.fuhrmann at gmail.com
Fri May 1 23:28:39 CEST 2020



> Am 01.05.2020 um 23:02 schrieb Rémi Denis-Courmont <remi at remlab.net>:
> 
> I don't see how not being able to open a device node means you have to hard code the path prefix and cannot use access.

This module can be opened with various paths of different types (obviously).
The main reason I wanted to add a check for device nodes is to make sure this message is only shown in the right situation. (There might be potentially other problems why EPERM is raised for files and folders, and this can not be fixed by the description given in the message.)

So the question is still as I have written earlier:
"Does anybody knows another different way to check if a path is a device node, without opening the file?“

I do not fully understand what you mean with "use access“, and how this can solve the described problem.

BR. David

> 
> And it won't work if you get a relative path.
> 
> Le 1 mai 2020 23:57:02 GMT+03:00, David Fuhrmann <david.fuhrmann at gmail.com> a écrit :
> 
> 
>> Am 01.05.2020 um 22:46 schrieb Rémi Denis-Courmont <remi at remlab.net <mailto:remi at remlab.net>>:
>> 
>> Hi,
>> 
>> I think everybody understood that the first time. I don't see how that answers my questions though.
> 
> 
> That is great, I was not so sure. :-)
> 
> But unfortunately, now I need to ask you to please reformulate your questions, as I do not understand them. And please also explain how that relates to my questions, and whether you might have any concrete solutions to the points I asked.
> 
> Thanks,
> David
>> 
>> Le 1 mai 2020 23:41:35 GMT+03:00, David Fuhrmann <david.fuhrmann at gmail.com <mailto: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 <mailto: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 <mailto:remi at remlab.net>>:
>> 
>> Le perjantaina 1. toukokuuta 2020, 13.58.21 EEST david.fuhrmann at gmail.com <mailto:david.fuhrmann at gmail.com>
>> <mailto:david.fuhrmann at gmail.com <mailto:david.fuhrmann at gmail.com>> a> 
>> écrit :
>> From: David Fuhrmann <dfuhrmann at videolan.org <mailto: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/ <http://www.remlab.net/>
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel <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 <https://mailman.videolan.org/listinfo/vlc-devel>
>> -- 
>> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
>> _______________________________________________
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel <https://mailman.videolan.org/listinfo/vlc-devel>
> 
> -- 
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20200501/0f359077/attachment.html>


More information about the vlc-devel mailing list