Bug 334311 - our plugin installation story sucks
our plugin installation story sucks
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Gecko Maintainer
Fedora Extras Quality Assurance
FF3RawhideClose
:
: 367281 375831 379421 384641 (view as bug list)
Depends On:
Blocks: F8Target
  Show dependency treegraph
 
Reported: 2007-10-16 10:09 EDT by Bill Nottingham
Modified: 2014-03-16 23:09 EDT (History)
14 users (show)

See Also:
Fixed In Version: 2.0.0.10-3.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-12-20 11:46:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2007-10-16 10:09:34 EDT
Description of problem:

So, take a default install. Go to a page with flash. This helpfully redirects to
Adobe, where you can download a flash player RPM.  (or a repo RPM). You then
install it.

This will lead to working flash support:

1) only if you happen to have had nspluginwrapper installed (for both arches)
2) only if you *run by hand as root* mozilla-plugin-config -i
3) only have audio w/PA if you happen to decide to install libflashsupport

This is a really bad user experience. Note that if you then *remove* the
flash-player RPM, due to both the flash player %post scripts, and the links set
up by mozilla-plugin-config, *the plugin is still installed*.

Suggestions:

1) have firefox require nspluginwrapper
2) have nspluginwrapper require libflashsupport?
3) have triggers in nspluginwrapper that run on flash plugin installation
4) fix deinstallation

Version-Release number of selected component (if applicable):

firefox-2.0.0.6-11.fc8
nspluginwrapper-0.9.91.5-7.fc8
Comment 1 Martin Stransky 2007-10-16 10:49:47 EDT
My suggestions are:

- Add directory /usr/lib/mozilla/plugins to 64-bit firefox (so the 32-bit plugin
installation will be alway successful)

- Add mozilla-plugin-config to /usr/bin/firefox starting script. This utility is
designed to run as SETUID (that was my first idea how to do it) and it will
configure / remove / install all available plugins. This utility is written in C
and it's designed to be as fast as possible. 

In that case user have to only restart the browser after the plugin installation.
Comment 2 Martin Stransky 2007-10-16 10:52:57 EDT
> Note that if you then *remove* the flash-player RPM, due to both the flash
> player %post scripts, and the links set up by mozilla-plugin-config,
> *the plugin is still installed*.

This is a bug in the mozilla-plugin-config and I have it in my TODO list.

Comment 3 Bill Nottingham 2007-10-16 11:05:40 EDT
(In reply to comment #1)
> My suggestions are:
> 
> - Add directory /usr/lib/mozilla/plugins to 64-bit firefox (so the 32-bit plugin
> installation will be alway successful)

What does this directory have to do with anything - its presence or absence does
not affect how things work.
 
> - Add mozilla-plugin-config to /usr/bin/firefox starting script. This utility is
> designed to run as SETUID (that was my first idea how to do it) and it will
> configure / remove / install all available plugins. This utility is written in C
> and it's designed to be as fast as possible. 

It's a shell script - you can't run it setuid.

> In that case user have to only restart the browser after the plugin installation.

Firefox seems to handle plugin changes fairly easily without restarts.

Note that both running mozilla-plugin-config and fixing deinstallation should be
able to be done pretty easily with a yum plugin. I should have a test one soon.

Question: *without* nspluginwrapper installed, does firefox look in the 'normal'
plugin directories?
Comment 4 Martin Stransky 2007-10-16 11:25:34 EDT
> (In reply to comment #1)
> > My suggestions are:
> > 
> > - Add directory /usr/lib/mozilla/plugins to 64-bit firefox (so the 32-bit plugin
> > installation will be alway successful)
> 
> What does this directory have to do with anything - its presence or absence does
> not affect how things work.

How do you want to install any 32-bit plugin if the directory for it is not
here??? It fails, right?
  
> > - Add mozilla-plugin-config to /usr/bin/firefox starting script. This utility is
> > designed to run as SETUID (that was my first idea how to do it) and it will
> > configure / remove / install all available plugins. This utility is written in C
> > and it's designed to be as fast as possible. 
> 
> It's a shell script - you can't run it setuid.

Sure, it's just a shell script what sets all paths and run the
/usr/lib(64)/nspluginwrapper/plugin-config binary. This plugin-config does all
the installation work.
 
> > In that case user have to only restart the browser after the plugin
installation.
> 
> Firefox seems to handle plugin changes fairly easily without restarts.
> 
> Note that both running mozilla-plugin-config and fixing deinstallation should be
> able to be done pretty easily with a yum plugin. I should have a test one soon.

The yum solution can not cover third party plugins (i.e. the rpm flash package
from Adobe. Do you expect they are going to change their package because of our
plugin model?). 

But if we run mozilla-plugin-config before the browser start it can handle any
situation (plugin is newly installed, plugin is missing, wrapping/linking is
broken...)

> 
> Question: *without* nspluginwrapper installed, does firefox look in the 'normal'
> plugin directories?

Yes. Without nspluginwrapper package ff uses the old plugin directory.
Comment 5 Bill Nottingham 2007-10-16 11:43:03 EDT
(In reply to comment #4)
> > (In reply to comment #1)
> How do you want to install any 32-bit plugin if the directory for it is not
> here??? It fails, right?

No, rpm happily creates the directory.
   
> > Note that both running mozilla-plugin-config and fixing deinstallation should be
> > able to be done pretty easily with a yum plugin. I should have a test one soon.
> 
> The yum solution can not cover third party plugins (i.e. the rpm flash package
> from Adobe. Do you expect they are going to change their package because of our
> plugin model?). 

It seems to work OK for me. Try:

http://people.redhat.com/notting/firefox-plugin.py ->
/usr/lib/yum-plugins/firefox-plugin.py
http://people.redhat.com/notting/firefox-plugin.conf ->
/etc/yum/pluginconf.d/firefox-plugin.conf

Also pulls in libflashsupport for flash-plugin if pulseaudio is installed.
(Admittedly, that's a hack).

> But if we run mozilla-plugin-config before the browser start it can handle any
> situation (plugin is newly installed, plugin is missing, wrapping/linking is
> broken...)

We can do this instead, yes. Concerns:
- may need modifications to firefox SELinux policy
- probably need to audit the setuid helper
- would need to make firefox require nspluginwrapper
Comment 6 Martin Stransky 2007-10-16 12:04:11 EDT
(In reply to comment #5)
> It seems to work OK for me. Try:
> 
> http://people.redhat.com/notting/firefox-plugin.py ->
> /usr/lib/yum-plugins/firefox-plugin.py
> http://people.redhat.com/notting/firefox-plugin.conf ->
> /etc/yum/pluginconf.d/firefox-plugin.conf
> 
> Also pulls in libflashsupport for flash-plugin if pulseaudio is installed.
> (Admittedly, that's a hack).

I admit I've never used that yum plugins. How is it supposed to work? Is it run
after the firefox/nspluginwrapper/any other package installation/removing via yum? 

If so, it doesn't solve our problem with Adobe RPM. (or any other third party
plugins distributed in binary rpm what are not in our repositories).

> We can do this instead, yes. Concerns:
> - may need modifications to firefox SELinux policy

Yes, that's right. But we have to do that, anyway. There are still some problems
there.

> - probably need to audit the setuid helper

Yes. But I've expected it. All string/paths are checked, it doesn't fetch any
command line argument in setuid mode. It just restores the plugin configuration
and quits.

> - would need to make firefox require nspluginwrapper

No, firefox will not run that config script if it's missing. Simple if [ -f ...
] can manage it.
Comment 7 Bill Nottingham 2007-10-16 12:23:21 EDT
(In reply to comment #6)
> I admit I've never used that yum plugins. How is it supposed to work? Is it run
> after the firefox/nspluginwrapper/any other package installation/removing via
yum? 

It runs during the transaction, running the plugin config and/or adding
libflashsupport, as needed. Trust me, it works.

My other concern about running the script only at startup is that it requires
restarting the browser for any plugin changes, which is something that's not
generally required in firefox.
Comment 8 Matěj Cepl 2007-10-16 17:29:04 EDT
I think I can safely conclude that issue described here is real and doesn't need
any further triage. ASSIGNED.
Comment 9 Lubomir Kundrak 2007-10-19 06:01:15 EDT
Would it be possible to avoid mozilla-plugin-config being SETUID by using a
directory relative to ~ instead of a system-wide for the wrapped plugins?
Something like ~/mozilla/plugins-wrapped?

It would allow for better configurability by user (choose which plugins does
he/she to be wrapped), similarly to what's currently possible with
~/.mozilla/plugins.
Comment 10 Bill Nottingham 2007-10-19 12:35:04 EDT
As nspluginwrapper/moz-plugin-config does *copies* of the plugins, this would
cause plugins to still be active on uninstall.
Comment 11 Martin Stransky 2007-10-22 05:54:00 EDT
(In reply to comment #7)
> It runs during the transaction, running the plugin config and/or adding
> libflashsupport, as needed. Trust me, it works.

How is is supposed to work? I copied your files to its locations, installed
nspluginwrapper package and flash rpm and nothing happened.
/usr/lib/mozilla/plugins-wrapped is empty....

Comment 12 Martin Stransky 2007-10-22 09:11:47 EDT
(In reply to comment #10)
> As nspluginwrapper/moz-plugin-config does *copies* of the plugins, this would
> cause plugins to still be active on uninstall.

fixed in nspluginwrapper-0_9_91_5-8. All dangling symlinks/wrapped plugins are
removed in install and forced check command.
Comment 13 Colin Walters 2007-10-22 12:22:39 EDT
1) is an issue only for 64 bit desktops, correct?

2) Not sure what's going on with mozilla-plugin-config

3) Can we just make firefox Require libflashsupport?  It's a tiny .so.
Comment 14 Warren Togami 2007-10-22 12:31:10 EDT
1) As far as the nspluginwrapper part of this problem goes, yes.

3) That would guarantee that our problems go away.  Currently libflashsupport
gets pulled in by comps default if the user selects Graphical Internet (along
with firefox).  But this doesn't help upgrading.

I think adding the Requires from firefox, seamonkey, kdebase (konqueror) would
make it Just Work.  Will we accept this? 
Comment 15 Bill Nottingham 2007-10-22 15:13:32 EDT
Re(In reply to comment #12)

> fixed in nspluginwrapper-0_9_91_5-8. All dangling symlinks/wrapped plugins are
> removed in install and forced check command.

'install' in this case is... install of nspluginwrapper? Someting else?

Comment 16 Bill Nottingham 2007-10-22 15:28:00 EDT
The reason I ask is that simply changing what moz-plugin-config does doesn't fix
the fact that you have to call it by hand when you install a plugin.
Comment 17 Martin Stransky 2007-10-23 02:40:18 EDT
(In reply to comment #15)
> > fixed in nspluginwrapper-0_9_91_5-8. All dangling symlinks/wrapped plugins are
> > removed in install and forced check command.
> 
> 'install' in this case is... install of nspluginwrapper? Someting else?

Sorry for quite vague specification. mozilla-plugin-config now clears all
dangling symlinks and dangling wrapped plugins from */mozilla/plugins-wrapped.

> The reason I ask is that simply changing what moz-plugin-config 
> does doesn't fix the fact that you have to call it by hand when 
> you install a plugin.

We need to run mozilla-plugin-config (if exist) after the plugin installation /
removal. I proposed to run it when browser is starting (as SUID). If you have
better solution please write it here.
Comment 18 Bill Nottingham 2007-10-23 13:14:06 EDT
That works - is that in the current firefox package?
Comment 19 Bill Nottingham 2007-10-23 17:17:19 EDT
I'm not seeing nspluginwrapper-0.9.91.5-8 in the latest F8 trees.
Comment 20 Martin Stransky 2007-10-24 04:07:29 EDT
(In reply to comment #18)
> That works - is that in the current firefox package?

No. If you want me to test it and apply it please attach some how-to.

> I'm not seeing nspluginwrapper-0.9.91.5-8 in the latest F8 trees.

F8 package is nspluginwrapper-0.9.91.5-9.fc8
Comment 21 Will Woods 2007-10-24 13:02:17 EDT
Does this mean our plugin installation story no longer sucks? Or is there still
work to be done?
Comment 22 Warren Togami 2007-10-24 13:31:23 EDT
nspluginwrapper-0.9.91.5-8.fc8 is the latest in F8.  If you have newer builds,
you must request their inclusion with rel-eng.
 
Comment 23 Bill Nottingham 2007-10-24 14:16:30 EDT
(In reply to comment #20)
> (In reply to comment #18)
> > That works - is that in the current firefox package?
> 
> No. If you want me to test it and apply it please attach some how-to.

I'm confused - you already said you wanted to run mozilla-plugin-config at
startup - what would you need from me?
Comment 24 Martin Stransky 2007-10-25 04:44:09 EDT
(In reply to comment #23)
> > No. If you want me to test it and apply it please attach some how-to.
> 
> I'm confused - you already said you wanted to run mozilla-plugin-config at
> startup - what would you need from me?

If I'm right you have proposed a solution based on yum (Comment #5) instead of
the mine, which is based on running the mozilla-plugin-config as SUID during a
browser startup.

I'd like to test your solution but it didn't worked for me (Comment #11). So if
you still prefer prefer your proposal please attach steps how set it up and how
is it supposed to work.

> Does this mean our plugin installation story no longer sucks? 
> Or is there still work to be done?

No, this issue is still alive and we need to do something what will configure
plugins in Fedora 8. 

Comment 25 Bill Nottingham 2007-10-25 10:53:52 EDT
If you want to do the suid+mozilla-plugin-config at startup, that's fine with me
as long as we document that you need to restart firefox after changing plugins.
Comment 26 Christopher Aillon 2007-10-25 17:50:53 EDT
(In reply to comment #25)
> If you want to do the suid+mozilla-plugin-config at startup, that's fine with me
> as long as we document that you need to restart firefox after changing plugins.

Restarting is the norm though after installing plugins in any way other than via
the Firefox Plugin Service (using the XUL dialogs that pop up, etc).  Also, oes
about:plugins not work here?
Comment 27 Martin Stransky 2007-10-26 05:15:03 EDT
SUID flag added to nspluginwrapper-0.9.91.5-10.fc8
(http://koji.fedoraproject.org/koji/taskinfo?taskID=215437).

I sent plugin-config review request to sec-standards-team@redhat.com.

If it goes well i'll release it as an F8 update.
Comment 28 Lubomir Kundrak 2007-10-26 06:51:35 EDT
Bad idea. Again, what was wrong with copying/linking the plugins to $HOME?
Comment 29 Bill Nottingham 2007-10-26 11:32:40 EDT
They won't get removed right on package deinstallation, and there are SELinux
issues involved there.
Comment 30 Bill Nottingham 2007-10-30 14:24:46 EDT
Moreover, wrapped plugins just plain *do not work* in the homedir.
Comment 31 Bill Nottingham 2007-10-30 14:31:08 EDT
Note that whatever is implemented as setuid in -10.fc{8,9} does not work. If run
by a regular user, it blows away the entire plugin registry.
Comment 32 Bill Nottingham 2007-10-30 14:45:24 EDT
Also, I'm less inclined to support the setuid approach after seeing it's over
2000 lines...
Comment 33 Bill Nottingham 2007-10-30 15:21:48 EDT
setuid does not work at the moment because you drop privs in process() when
looking at home directories, and pretty much every invocation calls process()
more than once to do different things, so all subsequent calls will fail for
system directories.
Comment 34 Martin Stransky 2007-10-31 07:44:23 EDT
try nspluginwrapper-0.9.91.5-11.fc8 and firefox firefox-2.0.0.8-3.fc8
Comment 35 Bastien Nocera 2007-10-31 07:53:23 EDT
(In reply to comment #34)
> try nspluginwrapper-0.9.91.5-11.fc8 and firefox firefox-2.0.0.8-3.fc8

Having to call mozilla-plugin-config on startup means that browsers such as
epiphany won't work as expected unless running that same command by hand.
Comment 36 Bill Nottingham 2007-11-01 10:49:16 EDT
That seems to work for me, even without restarting firefox (although I'm not
100% sure *how* it's working in that case)
Comment 37 Matěj Cepl 2007-11-12 05:15:46 EST
*** Bug 375831 has been marked as a duplicate of this bug. ***
Comment 38 Marcus Alves Grando 2007-11-15 19:54:09 EST
Works fine for me in firefox 2.0.0.9.

Regards
Comment 39 Lillian Angel 2007-11-21 11:23:14 EST
*** Bug 384641 has been marked as a duplicate of this bug. ***
Comment 40 Lillian Angel 2007-11-21 11:23:25 EST
*** Bug 379421 has been marked as a duplicate of this bug. ***
Comment 41 Lillian Angel 2007-11-22 10:13:23 EST
*** Bug 367281 has been marked as a duplicate of this bug. ***
Comment 42 Keith Roberts 2007-11-25 17:05:42 EST
Well, I have installed the adobe installer for Flashplayer OK. I have also 
installed FlashPlayer with yum and added the adobe repo to smart PM:

Adobe Flash Player 9.0

Adobe Flash Plugin 9.0.48.0
Fully Supported: Mozilla 1.0+, Netscape 7.x, Firefox 0.8+
Partially Supported: Opera, Konqueror 3.x

My only problem is that if I run X and KDE as root user, I have full 
FlashPlayer sound and video support.

However, if I run X and KDE as a normal user, video works ok, but I get no 
sound with the Flash downloads. Is this a permissions problem with devices?
Comment 43 Christopher Aillon 2007-11-26 07:24:13 EST
You need libflashsupport installed for sound.
Comment 44 Keith Roberts 2007-11-26 11:08:01 EST
Everything uninstalled and re-installed again as root user, including 
libflashsupport.

I re-installed in the following order:

firefox
libflashsupport
nspluginwrapper
flash-plugin

then did:

# mozilla-plugin-config -i

Still only had sound as root user that started X and KDE.

So I changed the settings for the following device files: (they all default to 
660 mode)

[root@karsites snd]# ls -l /dev/snd/
total 0
crw-rw-rw-+ 1 root root 116, 9 2007-11-26 15:42 controlC0
crw-rw-rw-+ 1 root root 116, 8 2007-11-26 15:42 pcmC0D0c
crw-rw-rw-+ 1 root root 116, 7 2007-11-26 15:42 pcmC0D0p
crw-rw-rw-+ 1 root root 116, 6 2007-11-26 15:42 pcmC0D1p
crw-rw-rw-+ 1 root root 116, 5 2007-11-26 15:42 pcmC0D2c
crw-rw-rw-+ 1 root root 116, 4 2007-11-26 15:42 pcmC0D2p
crw-rw-rw-+ 1 root root 116, 3 2007-11-26 15:42 seq
crw-rw-rw-+ 1 root root 116, 2 2007-11-26 15:42 timer
[root@karsites snd]#

[root@karsites snd]# ls -l /dev/audio
crw-rw-rw-+ 1 root root 14, 4 2007-11-26 15:42 /dev/audio
[root@karsites snd]#

[root@karsites snd]# ls -l /dev/dsp
crw-rw-rw-+ 1 root root 14, 3 2007-11-26 15:42 /dev/dsp
[root@karsites snd]#

This will allow an ordinary non-root user to access the sound device. *After* 
shuting down KDE and restarting X as a normal user, the sound now works fine 
for flash videos.

I have made these changes permanent by adding the following commands 
to /etc/init.d/rc.local

# F8 needs this for FlashPlayer sound to work as normal user
# and for a KDE normal user to access the sound device
chmod 666 /dev/snd/*
chmod 666 /dev/audio
chmod 666 /dev/dsp

Comment 45 Warren Togami 2007-11-26 11:23:15 EST
Are you starting KDE with startx or logging in from gdm?
Comment 46 Keith Roberts 2007-11-26 11:27:26 EST
>I have made these changes permanent by adding the following commands 
>to /etc/init.d/rc.local

woops - I mean't /etc/rc.d/rc.local
Comment 47 Keith Roberts 2007-11-26 11:29:26 EST
I'm starting KDE from a text console with startx. So I boot into text mode 
first, then optionally into X and KDE from the command line.
Comment 48 Warren Togami 2007-11-26 11:31:41 EST
> I'm starting KDE from a text console with startx. So I boot into text mode 
> first, then optionally into X and KDE from the command line.

There's your problem.  Logging in from startx, ConsoleKit fails to set
permissions of devices for your non-root user.  Your problem has nothing to do
with this bug # or Flash.
Comment 49 Keith Roberts 2007-11-26 15:37:22 EST
Thanks for pointing that out to me Warren. I'm the only user on the system - 
so I don't run ConsoleKit anyway as I don't need FUS. Here is a list of all 
the services that I start at boot time.

apcupsd
autofs
crond
cups
gpm
haldaemon
kar-firewall
kar-postgresql
kudzu
messagebus
nasd
network
ntpd
postfix
proftpd
rsyslog
smolt
sshd
udev-post
yum-updatesd

Is it OK to set the permissions like I do from rc.local?
Comment 50 Matěj Cepl 2007-12-20 11:46:39 EST
We just updated the Firefox version in Fedora/development from 2.0 to a 3.0
pre-release version, which improves performance, memory usage, and fixes many
bugs and crashes.

Closing as CANTFIX since we aren't fixing bugs filed against 2.0 now that 3.0 is
in.  If this bug is still present in rawhide using a Firefox 3.0 version, please
re-open this bug.

Thanks and Happy Holidays
Comment 51 Bill Nottingham 2007-12-20 12:41:28 EST
This should be fixed in the F8 updates.

Note You need to log in before you can comment on or make changes to this bug.