If you use unveil() without pledge(), you do not get the special-case-file-exposures-for-libc behaviours that pledge() brings.
You are then responsible for all path exposure. Morgan Aldridge <morg...@makkintosshu.com> wrote: > 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
