AddDynamic should be a rare call - it's actually only set during tests, but not in normal use. The advantage of doing the stat() is that we avoid populating the broker mapping with permissions for directories that don't exist anyway. The directories we stat are all devices (so in memory) or things we expect to access. So the gain here is likely to be small. I can't think of an attack scenario whereby being able to read a path prefix (we force append a / during construction) for a file that didn't exist yet on startup allows you more leverage (read restriction are after all mostly there to prevent info leaks or exfiltrating sensitive information), but note that in some instances we do allow write access with AddDir too. You could conceivably write out fake devices or library dirs and then rely on bugs in other apps that read those. But then the user would have to be able write there to begin with, which isn't likely if the dir didn't already exist.
Bug 1580654 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
AddDynamic changes behavior depending on the result of the stat(), but it should be a rare call - it's actually only set during tests, but not in normal use. The advantage of doing the stat() is that we avoid populating the broker mapping with permissions for directories that don't exist anyway. The directories we stat are all devices (so in memory) or things we expect to access. So the gain here is likely to be small. I can't think of an attack scenario whereby being able to read a path prefix (we force append a / during construction) for a file that didn't exist yet on startup allows you more leverage (read restriction are after all mostly there to prevent info leaks or exfiltrating sensitive information), but note that in some instances we do allow write access with AddDir too. You could conceivably write out fake devices or library dirs and then rely on bugs in other apps that read those. But then the user would have to be able write there to begin with, which isn't likely if the dir didn't already exist.
AddDynamic changes behavior depending on the result of the stat(), but it should be a rare call - it's actually only set during tests, but not in normal use. The advantage of doing the stat() is that we avoid populating the broker mapping with permissions for directories that don't exist anyway. The directories we stat are all devices (so in memory) or things we expect to access. So the gain here is likely to be small. I can't think of an attack scenario whereby being able to read a path prefix (we force append a / during construction) for a file that didn't exist yet on startup allows you more leverage (read restrictions are after all mostly there to prevent info leaks or exfiltrating sensitive information), but note that in some instances we do allow write access with AddDir too. You could conceivably write out fake devices or library dirs and then rely on bugs in other apps that read those. But then the user would have to be able write there to begin with, which isn't likely if the dir didn't already exist.