Solene Rapenne <sol...@perso.pw> wrote: > On Wed, Sep 25, 2019 at 11:25:59AM -0500, joshua stein wrote: > > This patchset goes back to files in /etc/firefox for unveil file > > lists, and goes further and moves the pledge strings to separate > > files too. This should be the most secure version that is still > > tweakable at runtime. > > > > I switched away from using Firefox's NS_LOCAL_FILE_CONTRACTID/ > > NS_LOCALFILEINPUTSTREAM_CONTRACTID mechanisms to read a file, since > > they require a lot of internal setup to be done before they can be > > used (which is otherwise a good thing, because other things later in > > Firefox shouldn't have raw file access). Instead of those, I'm > > using the normal C++ API for reading the /etc/firefox files and this > > way I have been able to move the pledge/unveil calls earlier in the > > process startup. Unfortunately this also means that I can't > > dynamically detect the localized ~/Downloads directory, so if you > > use a different directory, you'll just need to modify the > > unveil.content and unveil.main files to change it. > > > > I tried the $TMPDIR shenanigans with the main process mkdtemp'ing > > somewhere in $TMPDIR (or /tmp), and then exporting TMPDIR as that > > directory so that everything else within Firefox uses that > > subdirectory as its temp directory, allowing /tmp to be removed from > > the unveil lists and only that subdirectory visible. Unfortunately > > the first thing to break was our own shm_open() which hard-codes > > /tmp and doesn't honor $TMPDIR. So that all was ripped out and > > we're back to full access to /tmp. > > > > If the mailing list mangles this again, it's at > > https://jcs.org/patches/firefox-port-unveil8.diff > > > > > > when opening a youtube video, after a few seconds (no need to start the > video) firefox stops with a pledge error. > > firefox[27483]: pledge "tty", syscall 54
The output file will be huge, but by now it is obvious what is required: ktrace -di firefox kdump > hugefile And search for that the last record of that pid/thread (because the pledge killed it), and provide that information. It is ioctl. But what ioctl, and sometimes it also matters what that fd is, so you can search upwards for when it is created. Such information will be enough to find it in the code quickly. BTW, this applies to all pledge work.
