102286 - nsPluginsDir::IsPluginFile() should properly check shared library files

Status: RESOLVED WONTFIX

(Core Graveyard :: Plug-ins, defect, P4)

Description

[serge (gone)]

This bug is derived from bug 97362, and it is about properly implementation of 
nsPluginsDir::IsPluginFile() for unix
Here is an appropriate comment how to do this:
------- Additional Comments From [e-mail] 2001-08-30 06:40 -------

Third-party vendors can install plugins, users can, almost anyone can.
There's no reason to assume they will get it right so I think mozilla
needs to protect itself from random garbage. I would think that
protection is worth the cost. It should only be a few milliseconds in
time.

I don't understand your comment about symlinks. Mozilla shouldn't care
about symlinks at all in this context. You're interested in the link
target not the link.

Since shared libraries need to be executable, mozilla can save some time
by ignoring anything not executable by the process. That would mean
doing a stat on every file in a plugin directory but that's almost
always implicitly done anyway.

I guess one should also worry about special (in the POSIX sense) files
so I suggest an approach like this for each file:

1) stat (never lstat) the file and reject "special" and unknown files,
(forget you ever heard about symlinks).

2) reject any file that is not executable (really should deal with the
situation where effective uid != real uid).

3) reject any file that fails a magic number test.

Anything that passes all this is probably OK.

I have no idea if you want to recurse into sub-directories but that
wouldn't be hard either.

Yes, this is quite paranoid but you almost certainly want to be.

Comment 1

[scottputterman]

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+,
topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword.  Please send any
questions or feedback about this to [e-mail].  You can search for
"Moving bugs not scheduled for a project" to quickly delete this bugmail.