[leuk_he]

If i run emule as a secure user it fails to associate ed2k links with emule.

the property "autotake ed2k links" is disabled.

i think this can be solved by setting the registy entry before switching to a non-priviledged user or by assinging enough rights (security settings) to the part of the registry as is required.

(this is only an issue when running as secure user.)

Normally users do not have problems with this since the default is not a secure user, and once the registry is set everything syas fine. but i happened to move my emule directory and after using ed2k link killer the link never came back.

[alf]

The current behaviour is what I would expect from a security viewpoint. If you are running as a limited user then you can't change system files, registry settings or whatever is outside the scope of the "eMule secure" account. So if somehow one day a security hole is discovered in eMule and someone takes advantage of it to gain control of your eMule, that's all he will get, he won't be able to change your registry, run other programs, etc... (granted that you have set up the proper priviledges on your system)

So yes, while running as a secure user you can't use the "autotake ed2k links", but you will be running eMule with a higher security than the default settings.

[leuk_he]

alf, on Mar 12 2005, 03:09 PM, said:

So yes, while running as a secure user you can't use the "autotake ed2k links", but you will be running eMule with a higher security than the default settings.

well the secure user is not as secure as you think. I.e. it is still possible to preview files, and (from that) to run executables/scripts.

My only request is that the first check to take ed2k links is done before going to secure mode. (deregistering the lihnk on exit will be a problem.)

and of this behaviour needs to be documented

[donq]

Maybe should eMule installer (or eMule itself?) alter HKCR\ed2k registry key security to allow secure eMule user to change key contents?

But this is already security risk - this way unprivileged hacked eMule could change ed2k handler to run something malicious.

Most probably won't happen.

There's not nice to register ed2k to current eMule at startup and leave it after. Some nasty media players do that by default (fortunately not with ed2k). Although in some sense better than current behavior, this may surprise people, using other ed2k clients.

Solution is run eMule once as admin user and map ed2k link to eMule (not by using autotake).
If you're playing with different eMules and want to use ed2k autotake - you should manually change registry key permissions (using regedit). I hope this works

[leuk_he]

donq, on Mar 14 2005, 05:48 PM, said:

There's not nice to register ed2k to current eMule at startup and leave it after. Some nasty media players do that by default (fortunately not with ed2k). Although in some sense better than current behavior, this may surprise people, using other ed2k clients.

s

sharaza takes the ed2k link association by force and since my emule was runnign as secure i failed to recapture the link. I took too long too figure out that the secure user was the problem.

[alf]

leuk_he, on Mar 13 2005, 08:30 PM, said:

well the secure user is not as secure as you think. I.e. it is still possible to preview files, and (from that) to run executables/scripts.

If you remove the priviledges of the secure user to access anything beyond its directory you won't be able to preview files and so the risk would be null. (No, I haven't bothered to really test it myself)

leuk_he, on Mar 13 2005, 08:30 PM, said:

My only request is that the first check to take ed2k links is done before going to secure mode. (deregistering the lihnk on exit will be a problem.)

As you point out, it could be done while the eMule is still running as a normal user, but then the problem it would be to set the setting back to what it was before.

If you are running only one eMule in your computer the easiest solution is the one that donq wrote, and place a request in shareaza forums to be less aggressive with regards to protocol associations.

Quote

and of this behaviour needs to be documented   

I fully agree. Even something as easy as a tooltip over the setting: "this can't be used while running as a secure user" would be a good starting point.