On Wed, Jan 09, 2008 at 11:06:59PM -0500, Eric Dorland wrote: > forcemerge 229547 451327 ... > > This has some obvious, and perhaps some not so obvious, security issues. > > Please don't file duplicate bugs. What precisely are the security risks?
ok, sorry, did too limited search. About security: - 1st off, assuming that [EMAIL PROTECTED] == [EMAIL PROTECTED] is wrong - it's like saying that [EMAIL PROTECTED] == [EMAIL PROTECTED] so emailing either is the same ;) Checking just WM_CLIENT_MACHINE - if FF does so, as someone suggested - is not enough. Moreover, from http://www.x.org/wiki/FAQMiscellaneous: Q. How do I find out which process owns a given window? A. ... This is via two properties, _NET_WM_PID and WM_CLIENT_MACHINE. ... However, there are several caveats: ... 3. Most Importantly, the contents of the properties is entirely within the control of the application itself! This means that a malicious application could easily report false values! - eg: [EMAIL PROTECTED] != [EMAIL PROTECTED] you're tweaking the remote FF's config, you need some secrets from a protected URL. You start local FF (so you think), you get the uid+pwd dialog (you think you had already stored them in your browser, but may be not? nevertheless, you're in a hurry ...), put in uid+pwd and click the 'remember me' flag. But you stored such credentials in [EMAIL PROTECTED]'s FF! - eg: [EMAIL PROTECTED] != [EMAIL PROTECTED] same as above, but you start local FF (so you think) like firefox ftp://name:[EMAIL PROTECTED] which remains in remote's history. - eg: [EMAIL PROTECTED] != [EMAIL PROTECTED] same as above, but you've a local instance of eg. thunderbird; you open a private/reserved attachment whose MIME type makes TB spawn FF: it'd either fail, if the doc need be fetched from local fs (eg local /tmp) or succeed, if it get's retrived via network, in which case it'd remain cached in remote. - same as latter above, but for a private/reserved URL. - of course, invert local<->remote for similar scenario - possibly other cases, where you think you're browsing via a filtering proxy but you're actually not, etc. I think that's enough to show that FF check is way too weak, and dangerous. OTOH I see cases where you'd like it behave that way, eg. HOME of [EMAIL PROTECTED] if NFS exported/mounted to [EMAIL PROTECTED], so actually [EMAIL PROTECTED] == [EMAIL PROTECTED] I think a resonably safe way to let FF decide to spawn another instance of an already running FF, is to check for a fs-stored magic, along with its .lock: if [ -e .lock ] && [ fs-stored-magic = magic-from-running-FF ] spawn other instance of same PID else start an independent instance fi thanks -- paolo GPG/PGP id:0x1D5A11A4 - 04FC 8EB9 51A1 5158 1425 BC12 EA57 3382 1D5A 11A4 - 9/11: the outrageous deception and ongoing coverup: http://911review.org - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
