Windows Security/WebUI/Firefox - can't autoload torrent files

OK, here's a weird interaction for you. Hopefully someone out there has some answers as to what can be done to fix this.

I love running uTorrent with WebUI as a service. Got everything set up great and it works fine. The Download directory that I have Firefox pointed to is the same watched folder that uTorrent uses to pick up torrent files. As long as I'm logging the uTorrent service on as System or myself, everything's great.

Here's the rub - I want to segment the uTorrent service as its own user (for security). If the uTorrent process gets hacked somehow, I don't want it to have access to the whole system. This works fine in theory, but there's one little problem. When i download a .torrent file, the designated user (call it T) does not have access to the file in the download directory, and the uTorrent service running as T cannot touch it.

Fine, knowing how Windows security works, I figured that T must be in the permissions list for the downloads folder. No problem. Did that - no dice.

OK, let's try this - add a new group (call it Tg), add myself and T to that group. Give Tg full permissions to the Downloads folder. No go.

Ownership? T now owns the Downloads folder - still no go.

OK, let's just try "copy and paste" of the file (duplicate the .torrent file) in the Downloads folder... hey, the copy just loaded!

I've investigated a bit farther and what I've discovered is this:

1) When a file is created in Windows, that file had Ownership set to the user that created the file. All other permissions are inherited from the folder that the file is in at the time of creation. When that file is moved (not copied), it still retains the permissions of the original folder, and is not updated with the permissions of the new folder. (I guess you could call this a "feature" - you don't expose sensitive files by a simple move)

2) Firefox, when downloading, creates the downloaded file in a temporary space and moves (not copies) the file to the specified download folder upon completion.

Because of this, the downloaded .torrent files cannot be read by anyone except Administrator, System and the user that created them. I see two possible solutions at this point - (1) run the uTorrent service as either System, Administrator, or myself (not acceptable to my security-paranoid self), or (2) give user T permissions on the temporary download folder that Firefox uses. One problem with number (2) - anyone know where Firefox downloads to? I'm having a bitch of a time finding it...

OK one more update. It appears that Firefox creates two files during a download - one "stub" file (a placeholder) with the name of the final downloaded file, and a .part file that is where the downloaded data is written to. This "stub" file is replaced with the .part file upon download completion.

The "stub" file has the correct permissions expected of a file created in the Downloads folder - the .part file does not. Any clues?

Solved (kinda)! In scanning through the Firefox source, I noticed that all "helper" applications go through the same folder - the OS Temp folder. (In Windows XP, that's "C:\Documents and Settings\<username>\Local Settings\Temp" ) Downloads are treated as "helpers" inside Firefox, so the .part file is created there first, then moved to the final location. Yuck!

So, I gave user T read only permissions to the Temp folder - no go. T must have read and write permissions to successfully load the .torrent - so i added that to the Temp folder, and off we go!

Oh man, that's ugly, but it now works.

Any other suggestions (besides hacking the Firefox source, that is)?

TBH, what you've done sounds like the only reasonable workaround (or at least the only thing I might've come up with as well) =\

I have submitted the issue as a bug in Firefox (as this does affect other downloads, not just .torrent files). You can see the bug report here:

https://bugzilla.mozilla.org/show_bug.cgi?id=367395

Its not a bug. Its exactly how it should work:

http://support.microsoft.com/kb/310316

By default, an object inherits permissions from its parent object, either at the time of creation or when it is copied or moved to its parent folder. The only exception to this rule occurs when you move an object to a different folder on the same volume. In this case, the original permissions are retained.

You can modify how Windows Explorer handles permissions when objects are moved in the same NTFS volume. As mentioned, when an object is moved within the same volume, the object preserves its permissions by default. However, if you want to modify this behavior so that the object inherits the permissions from the parent folder, modify the registry as follows:

1. Click Start, click Run, type regedit, and then press ENTER.

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer

3. On the Edit menu, click Add Value, and then add the following registry value:

Value name: MoveSecurityAttributes

Data type: DWORD

Value data: 0

4. Exit Registry Editor.

Thanks for the information about Windows default behavior. I figured that was the case (as I noted in my original post) and I can also see why you wouldn't want to automagically change the permissions based on containing folder. It would be a security feature in Windows, not a bug. The bug is in Firefox, for not handling this situation properly and changing the permissions of the final downloaded file just prior to renaming the .part file.

@Lord Alderaan: The problem at hand is that Firefox should be setting the permissions to match the directory that the user asked to download the files into, not the permissions that the temporary directory has -- it's only logical. If I wanted to download something to a directory I know is shared between users, I wouldn't want to be messing with permissions for every file I download into that directory via Firefox -- Firefox should (intelligently) figure out that the directory is shared between users, and set the file permissions properly after moving it.

Just mentioning its not a bug. More a feature request.

I absolutely agree that it would be logical to have the permission of the target folder. And it only happens when you download something to the same drive as where the temp folder is located which adds to the confusion.

But I'd rather see Firefox warning about this windows behavioral problem then create a workaround internally themselves. And if they create a workaround make it optional and IMHO turned off by default, or better, ask what to do on first occurrence of this problem.

The truth is most people won't encounter a problem with this behavior and Firefox meddling with file security settings seems like a large step to take. A step that imho should be avoided if posible.

Well, actually, it appears Mozilla acknowledges it as a major bug (and has since 2003). It's rather sad to see it having been left unfixed for so long.

Even if Mozilla didn't explicitly mark it as a bug themselves 3 years ago, I'd still consider it a bug. Why? I can't see it as an intended behavior. Modifying permissions is hardly a security risk -- if you have permissions to write the file to disk, and do so, then you own the file. As such, why would/should it be a security risk to change file permissions on your own file? Adding the ability to handle file permissions (assuming it isn't already in place) doesn't make Firefox any less secure than it currently is, and I can't see anyone exploiting that specific piece of code to gain system access (if that's what you were getting at) -- you already can gain system access through the other bunch of buffer overruns anyway.

I agree that it is not intended behavior. But the error for this lies with Microsoft not Firefox. If its to be considered a bug, it would be a bug in Windows. And Firefox could only create a workaround for that Windows bug.

If Firefox would start downloading directly to the destination file instead of a temp file I'd consider it solved. However this would mean Firefox would only start downloading a file when the destination has been chosen instead of the nifty function that it starts downloading a file as soon as you click it.

But saving to a temp file, then move it, then adjust the security settings to that of its parent folder if the destination and the temp folder are on the same partition sounds too awkward to me. And have you considered that you might have rights to move, modify, delete a file but not to change its permissions. On a default system it might work fine but then it might cause strange things to happen on system that have its file security tweaked. I don't like Firefox messing with File Security settings because it opens a whole new world of problems. I'd rather have them draw the line here and keep Firefox clean and simple and close to its core activities. IMHO it should avoid trying to solve behavioral oddities and bugs in the OS it runs on.

Copying the file instead of moving it would get my vote btw. That won't cause this behavior and it will reset the settings. Copying does consume a lot more resources though. In fact I would copy the current (unfinnished) file to the destination as soon as its chosen and continue the download process there.

Following my logic, this can't be a bug with Windows, as handling permissions in that way is intended behavior in Windows. Not working around that (intended behavior) so that the permissions handling is working as expected in Firefox can't be a bug created by Windows or Microsoft. Is it qualified as a bug in Firefox? Well, I guess my opinion (I suppose) is debatable, but Mozilla itself agrees it's a bug, so...

TBH, I don't even think the temporary directory should be used to download the file before it gets moved to the destination directory -- what's the problem with downloading directly to the destination directory immediately? (It's probably something they discussed before, but seeing as how I never followed Firefox development too deeply, I wouldn't know )

Its saves only 5 to 20 seconds but that still can seem a lot to people. The security settings are the only side effect.

Whether the behavior is wanted or annoying it is exactly as expected. A move operation within a partition on a windows 2000+ machine will include the files permissions. I don't see how that could could be considered a bug then. I can understand people list it as a bug in bugzilla and it stays there as a place to discuss it. But I wouldn't call it a real bug. And since Mozilla hasn't solved it in almost 4 years even though its rated Major I guess that they don't see it as something they should solve. There are a couple of workarounds and they haven't implemented any of those.

In fact I presume µtorrent also doesn't touch the security settings of files it moves to a completed folder on the same partition? Is that a bug too then?

You're getting something mixed up here. The move behavior within the context of Windows itself is expected. The move behavior within the context of µTorrent is expected, as that's what it's called: moving the files. The real comparison would be whether µTorrent downloads the files to a temporary directory first and then moves it to the destination directory -- obviously not, so no, I don't consider it a "bug" with µTorrent.

The move behavior within the context of Firefox, on the other hand, is not expected. If you went up to the average Joe and asked him whether he knew the file was moved from the temporary directory before being moved into the destination directory, do you think he'd say yes? No, any normal user would expect that the file wasn't moved, that if it's being told to download into that directory, it's going to be downloaded directly in there, without moving. Even if moving were required, the permissions should be identical to the target directory because you're telling Firefox exactly where to download the file to, not where to move it to.

To reply to that I would reason that even though users can expect something, it is the creators that intend something. And imho a bug must be unintended behavior and not just unexpected behavior. I guess its a question of opinion about what exactly a bug is.

Mozilla has had it officially classified as a bug in bugzilla. Mozilla MIGHT have just left it there because at one time or another they were planning on doing something about it (to implement a solution or work around to match the intended behavior to the expected behavior).

The fact that they haven't done just that could mean they leave the current thing as intended behavior (possibly because the alternatives are not preferable) or they haven't gotten around to implement a solutions yet. The fact that there have always been three known solutions (copy, wait until destination has been picked and set security afterwards) leads me to believe they have no intention to change the intended behavior.

I guess thats just how I feel about it.