@rozgwi im sorry I dont need to explain anything. First, I am the one who paid for this system and (even if only in part) your salary in case you work for Jolla;
second, my bug report is not about security (which you and others seem to keep liking to imply).
If you think my bug is not a bug, suck it up and close it, that is, in case you (or someone else) work for Jolla. Honestly I sincerely hope you do not work for them; if this is the attitude towards customers, I am not surprised of Jolla’s life in the past years.
1 Like
Im wondering, if the files are sandboxed, are they “dummy” in the sense as default ones? Or are they the “real” files? The firejail per se might not be providing suck “mocking” feature. I am mainly wondering how does android / iOs handle the same cases; and considering the phone not being a desktop.
@tortoisedoc hold your horses. I am sorry if I offended you. It really was not my intention.
Also, I’m not working for nor affiliated with Jolla. Just a user, as you. Should I have been overzealous changing the topics title and asking for a more specific description , I apologize.
Anyways. Thank you for updating your description and explaining what’s the issue from your point of view.
3 Likes
s/user/customer 
Same with me. passwd is no real issue as I told that shadow is not readable. But having the possibility to run around in /etc is no good choice…
1 Like
But why does it work with view-source?
Just readable /etc files. My firejailed/apparmored end user software on the desktop is not able to do that.
2 Likes
Unlike a web server the filesystem does not provide content-types. Therefore the browser has to guess. In this case the outcome is most likely text/plain. At least that’s what file proposes:
$ file --mime-type -b /etc/passwd
text/plain
And for web content with mimetype text/plain there is simply no difference between displayed content and source.
The cat’s out of the bag now. Accusing community members of not providing sufficient customer support in reply to unstructured complaints… haven’t seen that one before, have we?
3 Likes
AFAIU SFOS 4.x has introduced sandboxing for a few (more) apps, like Firefox? And it uses firejail for this?
Firejail has been doing this for a long time now (originally for Firefox as the name implies) and if they decided that the Firefox profile is allowed to read some files in /etc, just like a normal user can, then that’s it.
That’s the beauty of SFOS, it works like a Linux distro, no need to worry about Google’s mobile OS paradigm anymore.
That said, there’s been criticism of firejail not being secure enough. I suspect it’s the same security-buzzword-crazy Android millenials parroting that, but there it is.
But hey, I’m talking out my arse. I don’t positively know if SFOS 4.x uses firejail to sandbox Firefox, and whether it uses the default Firefox profile or something else…?
Clarifying that would be the next constructive step.
5 Likes
FYI the bug report has been updated.
JavaScript code is not allowed to access local files, which is enforced by the browser itself. This has been for quite a while (probably over 10 years by now), due to security concerns. But if an user manually enters a file-url in their browser address bar, the browser will go there.
If you’re not convinced, I’ve thrown together a quick test page you can test out if the browser blocks things. Note that if you download the page, using the link found at the bottom, and open it from your file system, some of the links will work!
Edit:
It seems like the browser has some interesting, unexpected behaviour:
- Open the link opened above in the Sailfish Browser (not in private browsing mode). It does not load the images linked from the local file system, as expected.
- Download the html file at the link at the bottom of the page and open it in the browser, while leaving the previous tab open. It does load the images from the file system, as expected.
- Close the browser.
- Reopen the browser. It will show the locally stored HTML file, with the images loaded from the file system, as expected.
- Switch to the tab you opened at step 1. It does show the images from the local file system, which should not happen!
1 Like
Maybe these have been cached by FF? So it’s not actually showing the files from the filesystem, it’s showing those in FF’s cache?
The image is not showing up anymore on 4.5.0.24.
But opening the html still allows to link to /etc/passwd.
Don’t really know if this is an issue…
How would it have cached the images, if it its not supposed to load them in the first place ?
There seems to be some bitrot here after all…
as far as i know in a linux or unix system any file in /etc is given read access to any user
etc means “editable text configuration” i wonder if the system would work at all if this read access was denied to a regular user
1 Like
The question is more if the jail the browser is running in should have access to it. But maybe?
Indeed system access is one thing, browser access another.
It remains to be seen if the whole filesystem is also accessible from the browser…i.e. not only etc…
from above aloready gallery pictures seem to be as well…
So what I am wondering here is, is there some bitrot somewhere that potentially gives access to some private data…and which should be fixed.
btw editable text configuration → I was missing this piece, thanks! 
1 Like
It is also (in addition to repeating what was stated above, that reading passwd is normal, harmless, and required) important to note that what you see in file:///etc is NOT the full content of /etc.
Rather, through sailjail, the browser sees a read-only copy of some of the files from that dir.
It may be interesting to some to read up on the private-etc, blacklist, whitelist, and read-only config settings of Firejail which explains how this works.
https://man7.org/linux/man-pages/man5/firejail-profile.5.html
4 Likes
Okay, thats great reference! Thanks!