We probably should limit FSAS to just a few "reasonably safe" directories, as it can be easily used to circumvent the filesystem veil. Afterall, if a program really really wants to access critical system files, it probably should include them in the initial veil as well.

Currently, Ladybird has virtually unlimited read-access to everything the user can read:

This feels like a bad idea. Why bother putting up a veil, when all the data is just one IPC call away?

I suggest that we only whitelist the following directories:

• $HOME
• /res (because that's where all our example-html lives)
• /tmp/ (in case the user uses that directory to handle files)
• /usr/ (Tests, include files, shared libraries, installed ports, and a copy of the entire serenity source code live here)

This would mean that the following directories would become inaccessible through FileSystemAccessServer:

• /bin/
• /dev/
• /etc/
• /mnt/
• /proc/
• /sys/
• /var/ – contains only /var/run/utmp at the moment
• /www/ – these files should be served by WebServer

As far as I can see, the following programs currently use this promptless mechanism by FSAS:

• 3DFileViewer (cli args, drag&drop sources, texture files)
• Font Editor (cli args, recent files, drag&drop sources)
• HexEditor (only recent files)
• ImageViewer (cli args, recent files, drag&drop sources, reading files during dir traversal – irritatingly, it does NOT use FSAS to do the dir traversal itself, but there's a FIXME near its unveil block.)
• PDFViewer (cli args, recent files)
• PixelPaint (cli args, recent files)
• SpreadSheet (cli args, recent files)
• TextEditor (cli args, recent files, drag&drop sources)
• ThemeEditor (cli args)
• VideoPlayer (cli args, drag&drop sources)
• GMLPlayground (cli args, recent files, drag&drop sources)
• LibWebView (for file://)

None of these applications have any business reading directly from the above-mentioned "would become inaccessible" directories. Let me know what you think!