On Mon, Aug 7, 2023 at 3:57 AM Landry Breuil <lan...@openbsd.org> wrote:
> Le Sat, Aug 05, 2023 at 07:41:12PM -0400, George Koehler a écrit : > > On Sat, 5 Aug 2023 08:49:25 +0200 > > Landry Breuil <lan...@openbsd.org> wrote: > > > > > I'm not sure i'll be able to look into it, but i'd rather *not* > document > > > 'workarounds' for issues until we're sure the issue isnt fixable. Maybe > > > it's pledge/unveil related, maybe not. Using ktrace to figure out which > > > files the browser tries to access when handling date-related functions > > > might help... and if it's not an issue happening only on OpenBSD, then > > > dealing with upstream is the way to go. > > > > I used ktrace. It's unveil. The fix is to add "/etc/localtime r" > > to /etc/firefox/unveil.content > > many thanks george for the time spend of this and this detailed > analysis. Definitely ok for me to add `/etc/localtime r` to > /etc/firefox/unveil.content, if it doesnt need to unveil the full > usr/share/zoneinfo subdir thats even simpler. > Replicating George's test with the firefox port's default (unfixed) /etc/firefox/unveil.content. I used my Xsunaba utility just to simplify testing firefox as a fresh user, plus my own date_test.html (attached) which calls the `new Date().toString()`, `Intl.DateTimeFormat().resolvedOptions().timeZone`, and `new Date().toLocaleString()` JavaScript methods: $ Xsunaba ktrace -di -f /home/xsunaba/firefox-stable-default-ktrace.out firefox /home/xsunaba/Downloads/date_test.html 27628 is a content process that has called unveil and pledge: $ doas -u xsunaba kdump -HT -f /home/xsunaba/firefox-stable-default-ktrace.out | grep 27628\\/ | less libc still is able to successfully open /etc/localtime first: 27628/276891 firefox 1692576139.506386 CALL open(0xe92e849aac8,0<O_RDONLY>) 27628/276891 firefox 1692576139.506392 NAMI "/etc/localtime" 27628/276891 firefox 1692576139.506411 RET open 41/0x29 Then the content process cannot call realpath() on /etc/localtime as unveil(2) hides it: 27628/276891 firefox 1692576139.522045 CALL __realpath(0xe92d022a315,0x774762945ea0) 27628/276891 firefox 1692576139.522048 NAMI "/etc/localtime" 27628/276891 firefox 1692576139.522059 RET __realpath -1 errno 2 No such file or directory It also fails to access /usr/share/zoneinfo/* due to being hidden by unveil(2): 27628/276891 firefox 1692576139.522089 CALL open(0xe92cffe36a6,0x30000<O_RDONLY|O_CLOEXEC|O_DIRECTORY>) 27628/276891 firefox 1692576139.522094 NAMI "/usr/share/zoneinfo/" 27628/276891 firefox 1692576139.522103 RET open -1 errno 2 No such file or directory The firefox JS console outputs the following inconsistent date/time/zone: Sun Aug 20 2023 18:02:19 GMT-0600 (GMT-06:00) EST 8/20/2023, 7:02:19 PM * * * After adding '/etc/localtime r' to /etc/firefox/unveil.content: $ Xsunaba ktrace -di -f /home/xsunaba/firefox-stable-unveil_localtime-ktrace.out firefox /home/xsunaba/Downloads/date_test.html 61062 is a content process that has called unveil and pledge: $ doas -u xsunaba kdump -HT -f /home/xsunaba/firefox-stable-unveil_localtime-ktrace.out | grep 61062\\/ | less libc is still able to successfully /etc/localtime first: 61062/172260 firefox 1692578044.321975 CALL open(0x8df50322ac8,0<O_RDONLY>) 61062/172260 firefox 1692578044.321982 NAMI "/etc/localtime" 61062/172260 firefox 1692578044.321999 RET open 41/0x2 Then the content process can call realpath() on /etc/localtime as unveil(2) is no longer hiding it: 61062/172260 firefox 1692578044.333193 CALL __realpath(0x8e03868b315,0x77b1cc5407f0) 61062/172260 firefox 1692578044.333199 NAMI "/etc/localtime" 61062/172260 firefox 1692578044.333210 NAMI "/usr/share/zoneinfo/America/New_York" 61062/172260 firefox 1692578044.333214 RET __realpath I no longer see an attempt nor error to open /usr/share/zoneinfo/. The firefox JS console outputs the following correct date/time/zone: Sun Aug 20 2023 20:34:04 GMT-0400 (Eastern Daylight Time) America/New_York 8/20/2023, 8:34:04 PM * * * In conclusion this does seem to resolve all the cases that I had identified and since my second test doesn't seem to even attempt to open /usr/share/zoneinfo, I believe that just unveiling /etc/localtime is sufficient. I see that George has already committed unveiling /etc/localtime for firefox content processes in the port, so many, _many_ thanks to George and Landry! Morgan
