Bug 334311

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.

> 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.

(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?

> (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.

(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

(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.

(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.

I think I can safely conclude that issue described here is real and doesn't need
any further triage. ASSIGNED.

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.

As nspluginwrapper/moz-plugin-config does *copies* of the plugins, this would
cause plugins to still be active on uninstall.

(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....

(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.

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.

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? 

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?

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.

(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.

That works - is that in the current firefox package?

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

(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

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

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.
 

(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?

(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. 

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.

(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?

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.

If it goes well i'll release it as an F8 update.

Bad idea. Again, what was wrong with copying/linking the plugins to $HOME?

They won't get removed right on package deinstallation, and there are SELinux
issues involved there.

Moreover, wrapped plugins just plain *do not work* in the homedir.

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.

Also, I'm less inclined to support the setuid approach after seeing it's over
2000 lines...

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.

try nspluginwrapper-0.9.91.5-11.fc8 and firefox firefox-2.0.0.8-3.fc8

(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.

That seems to work for me, even without restarting firefox (although I'm not
100% sure *how* it's working in that case)

*** Bug 375831 has been marked as a duplicate of this bug. ***

Works fine for me in firefox 2.0.0.9.

Regards

*** Bug 384641 has been marked as a duplicate of this bug. ***

*** Bug 379421 has been marked as a duplicate of this bug. ***

*** Bug 367281 has been marked as a duplicate of this bug. ***

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?

You need libflashsupport installed for sound.

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

Are you starting KDE with startx or logging in from gdm?

>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

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.

> 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.

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?

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

This should be fixed in the F8 updates.