[vlc-devel] [PATCH 1/2] dvdnav: Limit user information about insufficient permissions
Rémi Denis-Courmont
remi at remlab.net
Fri May 1 23:02:23 CEST 2020
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.
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>:
>>
>> 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> 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/ <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
--
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/20200502/35f3627c/attachment.html>
More information about the vlc-devel
mailing list