This site will have limited functionality while we undergo maintenance to improve your experience. If an article doesn't solve your issue and you want to ask a question, we have our support community waiting to help you at @FirefoxSupport on Twitter and/r/firefox on Reddit.

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Rohkem teavet

How to prevent firefox from resolving symlinks

  • 4 vastust
  • 3 on selline probleem
  • 3 views
  • Viimati vastas txema.gonz

more options

Following "How to prevent version 13.0 from following symlinks"

I was developing a test framework and there was a symlink test.html inside every folder. As long as now firefox resolves symlinks, I promised to have a look at the code. (wonderful and marvelous mozilla code and docs. Thx people.)

I found in mozilla-central/netwerk/protocol/file/nsFileChannel.cpp

The following code

nsFileChannel::nsFileChannel(nsIURI *uri) {

 // If we have a link file, we should resolve its target right away.
 // This is to protect against a same origin attack where the same link file
 // can point to different resources right after the first resource is loaded.
 nsCOMPtr<nsIFile> file;
 nsCOMPtr <nsIURI> targetURI;
 nsAutoCString fileTarget;
 nsCOMPtr<nsIFile> resolvedFile;
 bool symLink;
 nsCOMPtr<nsIFileURL> fileURL = do_QueryInterface(uri);
 if (fileURL && 
     NS_SUCCEEDED(fileURL->GetFile(getter_AddRefs(file))) &&
     NS_SUCCEEDED(file->IsSymlink(&symLink)) && 
     symLink &&
     NS_SUCCEEDED(file->GetNativeTarget(fileTarget)) &&
     NS_SUCCEEDED(NS_NewNativeLocalFile(fileTarget, PR_TRUE, 
                                        getter_AddRefs(resolvedFile))) &&
     NS_SUCCEEDED(NS_NewFileURI(getter_AddRefs(targetURI), 
                  resolvedFile, nullptr))) {
   SetURI(targetURI);
   SetOriginalURI(uri);
   nsLoadFlags loadFlags = 0;
   GetLoadFlags(&loadFlags);
   SetLoadFlags(loadFlags | nsIChannel::LOAD_REPLACE);
 } else {
   SetURI(uri);
 }

}


If you force the false branch SetURI(uri) in any case, firefox stops resolving the symlinks. This is a very local solution, but as you can see in the first comment, resolving the symlink is intentional.

So the questions are:

 Is mozilla people going to provide another solution to solve security risks without breaking backward compatibility with our code?
Who do we have to post our question to?

Thanks to all for your support.

Following "How to prevent version 13.0 from following symlinks" I was developing a test framework and there was a symlink test.html inside every folder. As long as now firefox resolves symlinks, I promised to have a look at the code. (wonderful and marvelous mozilla code and docs. Thx people.) I found in mozilla-central/netwerk/protocol/file/nsFileChannel.cpp The following code nsFileChannel::nsFileChannel(nsIURI *uri) { // If we have a link file, we should resolve its target right away. // This is to protect against a same origin attack where the same link file // can point to different resources right after the first resource is loaded. nsCOMPtr<nsIFile> file; nsCOMPtr <nsIURI> targetURI; nsAutoCString fileTarget; nsCOMPtr<nsIFile> resolvedFile; bool symLink; nsCOMPtr<nsIFileURL> fileURL = do_QueryInterface(uri); if (fileURL && NS_SUCCEEDED(fileURL->GetFile(getter_AddRefs(file))) && NS_SUCCEEDED(file->IsSymlink(&symLink)) && symLink && NS_SUCCEEDED(file->GetNativeTarget(fileTarget)) && NS_SUCCEEDED(NS_NewNativeLocalFile(fileTarget, PR_TRUE, getter_AddRefs(resolvedFile))) && NS_SUCCEEDED(NS_NewFileURI(getter_AddRefs(targetURI), resolvedFile, nullptr))) { SetURI(targetURI); SetOriginalURI(uri); nsLoadFlags loadFlags = 0; GetLoadFlags(&loadFlags); SetLoadFlags(loadFlags | nsIChannel::LOAD_REPLACE); } else { SetURI(uri); } } If you force the false branch SetURI(uri) in any case, firefox stops resolving the symlinks. This is a very local solution, but as you can see in the first comment, resolving the symlink is intentional. So the questions are: Is mozilla people going to provide another solution to solve security risks without breaking backward compatibility with our code? Who do we have to post our question to? Thanks to all for your support.

All Replies (4)

more options

Link to earlier (closed) thread for reference: https://support.mozilla.org/en-US/questions/929923

more options

I have forked mozilla-central at github.com inside my profile (https://github.com/txemagon/) and I also have cloned it with hg (inbound-src as well)

I have changed nsFileChannel.cpp to accept a preference (about:config) network.file.allowSymlinks

Whenever is set to true then firefox gives up from resolving symlinks.

But, does someone know if I can make a pull request?

Is it possible to contact the module owner to discuss this change in mozilla? Where can I find him?

I'm pretty new to contributing so a warm face to lead my first steps would be just wonderful.

more options

Mozilla has a variety of development mailing lists, but I don't have a sense of which one is the most appropriate; maybe the general Firefox list? Also, have you considered creating a new bug on Bugzilla?

more options

I found a bug with the same issue. Added a comment referencing a possible solution. I'll keep you informed.