Sykje yn Support

Mij stipescams. Wy sille jo nea freegje in telefoannûmer te beljen, der in sms nei ta te stjoeren of persoanlike gegevens te dielen. Meld fertochte aktiviteit mei de opsje ‘Misbrûk melde’.

Mear ynfo

Dizze konversaasje is argivearre. Stel in nije fraach as jo help nedich hawwe.

How to prevent firefox from resolving symlinks

  • 4 antwurd
  • 3 hawwe dit probleem
  • 3 werjeftes
  • Lêste antwurd fan 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.

Alle antwurden (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.