Mozilla VPN is currently experiencing an outage. Our team is actively working to resolve the issue. Please check the status page for real-time updates. Thank you for your patience.

Ce site disposera de fonctionnalités limitées pendant que nous effectuons des opérations de maintenance en vue de vous proposer un meilleur service. Si un article ne règle pas votre problème et que vous souhaitez poser une question, notre communauté d’assistance est prête à vous répondre via @FirefoxSupport sur Twitter, et /r/firefox sur Reddit.

Rechercher dans l’assistance

Évitez les escroqueries à l’assistance. Nous ne vous demanderons jamais d’appeler ou d’envoyer un SMS à un numéro de téléphone ou de partager des informations personnelles. Veuillez signaler toute activité suspecte en utilisant l’option « Signaler un abus ».

En savoir plus

How to prevent firefox from resolving symlinks

  • 4 réponses
  • 3 ont ce problème
  • 3 vues
  • Dernière réponse par 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.

Toutes les réponses (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.