Bug 408111

Created attachment 275151 [details]
FDI file to enable all the above.

This FDI files set the properties required to implement these suggestions.

Created attachment 275161 [details]
PolicyKit policy file to implement the suggestions.

To implement these suggestions, drop the attachments at these locations:
/usr/share/hal/fdi/policy/10osvendor/19local.fdi
/usr/share/PolicyKit/policy/local.policy

Phil.

Adding krh as he wrote the Firewire stack

>   - Using Firewire cameras with dvgrab requires access to /dev/fw0 as 
>     well as the /dev/fwN of the camera itself.  Currently only /dev/fwN is
>     set read-write for the logged in user.

What is /dev/fw0? Is that the card? What are the (security) implications of
giving access to this node? One express purpose of the new Firewire stack, IIRC,
was that we could grant access on a per-device basis.

Kristian?

/dev/fw0 is the host controller and access to this device file is required for a
couple of streaming functions.  I don't see a problem in allowing access.

Also:

 - USB removable devices (/dev/sdX and /dev/sdXN) are not read-writable
   There is a legitimate need for the logged in user to have access to these
nodes (eg. for repartitionning).

I don't know about this one, but if we're doing it for usb removable storage, we
should do it for firewire too.

Regarding the other suggestions

(In reply to comment #0)
>  - USB removable devices (/dev/sdX and /dev/sdXN) are not read-writable
>    There is a legitimate need for the logged in user to have access to
>    these nodes (eg. for repartitionning).

Disagree. The partitioning utility just needs to be written in a way such that
it uses a privileged helper can does the work. This one is then locked down via
PolicyKit and exports PK actions like "partition", "create-file-system" etc.

It's way too dangerous to give write access, or even read, access to the device
nodes. Just with read access the user can bypass file system security.

So NAK on this one.

>  - The Palm Pilot devices (typ. /dev/ttyUSB*) are not set to be writable by the
> user.

I thought about adding this.. I see that you match on only what hal detects as
PDA's so I guess this is good. 

Maybe we should just allow access to any serial port that is exposed via USB? Or
maybe that's too dangerous.

>  - It would be nice to differentiate between different USB storage devices.
>    If you plug in a multifunction card reader, you may end up with four extra
> devices that all look the same in Nautilus.

This already works; just send patches to this file

http://gitweb.freedesktop.org/?p=hal-info.git;a=blob;hb=HEAD;f=fdi/information/10freedesktop/10-usb-card-readers.fdi

(In reply to comment #6)
>>  - USB removable devices (/dev/sdX and /dev/sdXN) are not read-writable
>>    There is a legitimate need for the logged in user to have access to
>>    these nodes (eg. for repartitionning).
>
> Disagree. The partitioning utility just needs to be written in a way such that
> it uses a privileged helper can does the work. This one is then locked down via
> PolicyKit and exports PK actions like "partition", "create-file-system" etc.
>
> It's way too dangerous to give write access, or even read, access to the device
> nodes. Just with read access the user can bypass file system security.
> 
> So NAK on this one.

I disagree on this NAK.
There is no filesystem security anyways on removable devices.
I can mount the same device on another system and put anything on the device
filesystem.  That's why we're mounting it noexec,nosuid,nodev anyways.
Making the device node not readable/writable by the use only prevents legitimate
operations without increasing security.

>>  - It would be nice to differentiate between different USB storage devices.
>>    If you plug in a multifunction card reader, you may end up with four extra
>> devices that all look the same in Nautilus.
>
> This already works; just send patches to this file
>
>
http://gitweb.freedesktop.org/?p=hal-info.git;a=blob;hb=HEAD;f=fdi/information/10freedesktop/10-usb-card-readers.fdi

I'm confused about your comment.
Yes, it already works.  The problem I was trying to solve is to put distinctive
icons on these devices.  The stock icons that are set in the fdi file I sent are
icons showing the type of card (as opposed to a generic "hard drive' icon).

Phil.

(In reply to comment #7)
> I disagree on this NAK.
> There is no filesystem security anyways on removable devices.
> I can mount the same device on another system and put anything on the device
> filesystem.  That's why we're mounting it noexec,nosuid,nodev anyways.
> Making the device node not readable/writable by the use only prevents legitimate
> operations without increasing security.

Depends on the context. It's not impossible for me to imagine enterprise and
government setups where they would care about this (a guard wouldn't allow you
to move removable media outside a secure facility). Also things like SarBox.

> I'm confused about your comment.
> Yes, it already works.  The problem I was trying to solve is to put distinctive
> icons on these devices.  The stock icons that are set in the fdi file I sent are
> icons showing the type of card (as opposed to a generic "hard drive' icon).

That's just a problem with your icon theme; works fine already for good old
Bluecurve

 http://people.freedesktop.org/~david/themed-icons.png

Unfortunately the problem here is that the Tango and gnome-icon-theme people
just symlinked the class specific icons

$ ls -l /usr/share/icons/Tango/22x22/devices/gnome-dev-media-cf.png
/usr/share/icons/gnome/22x22/devices/gnome-dev-media-cf.png
lrwxrwxrwx 1 root root 15 2007-09-20 10:19
/usr/share/icons/gnome/22x22/devices/gnome-dev-media-cf.png -> media-flash.png
lrwxrwxrwx 1 root root 15 2007-09-10 07:28
/usr/share/icons/Tango/22x22/devices/gnome-dev-media-cf.png -> media-flash.png

because they thought it was too confusing. Sigh. Go figure. However, for Fedora
9 this will hopefully get fixed as we have icon naming fallback.

So how do we move forward? I'm open for taking the ttyUSB and Firewire stuff.
Sounds good?

     David

(In reply to comment #8)
> (In reply to comment #7)
> > I disagree on this NAK.
> > There is no filesystem security anyways on removable devices.
> > I can mount the same device on another system and put anything on the device
> > filesystem.  That's why we're mounting it noexec,nosuid,nodev anyways.
> > Making the device node not readable/writable by the use only prevents legitimate
> > operations without increasing security.
> 
> Depends on the context. It's not impossible for me to imagine enterprise and
> government setups where they would care about this (a guard wouldn't allow you
> to move removable media outside a secure facility). Also things like SarBox.

This scenario looks quite a stretch, but I understand your position.
I agree with your NAK then.

> > I'm confused about your comment.
> > Yes, it already works.  The problem I was trying to solve is to put distinctive
> > icons on these devices.  The stock icons that are set in the fdi file I sent are
> > icons showing the type of card (as opposed to a generic "hard drive' icon).
> 
> That's just a problem with your icon theme; works fine already for good old
> Bluecurve
> 
>  http://people.freedesktop.org/~david/themed-icons.png
> 
> Unfortunately the problem here is that the Tango and gnome-icon-theme people
> just symlinked the class specific icons
> 
> $ ls -l /usr/share/icons/Tango/22x22/devices/gnome-dev-media-cf.png
> /usr/share/icons/gnome/22x22/devices/gnome-dev-media-cf.png
> lrwxrwxrwx 1 root root 15 2007-09-20 10:19
> /usr/share/icons/gnome/22x22/devices/gnome-dev-media-cf.png -> media-flash.png
> lrwxrwxrwx 1 root root 15 2007-09-10 07:28
> /usr/share/icons/Tango/22x22/devices/gnome-dev-media-cf.png -> media-flash.png
> 
> because they thought it was too confusing. Sigh. Go figure. However, for Fedora
> 9 this will hopefully get fixed as we have icon naming fallback.

I'm still confused here.
How can the desktop display the correct icons if HAL returns the wrong icons?
I might be missing something.

> So how do we move forward? I'm open for taking the ttyUSB and Firewire stuff.
> Sounds good?

Ok.

Phil.

(In reply to comment #9)
> > Depends on the context. It's not impossible for me to imagine enterprise and
> > government setups where they would care about this (a guard wouldn't allow you
> > to move removable media outside a secure facility). Also things like SarBox.
> 
> This scenario looks quite a stretch, but I understand your position.
> I agree with your NAK then.

It's a huge stretch, yeah. It's also about being secure out of the box. I can
imagine tons of admins who would be caught by surprise. Including those running
a Fedora box off a USB storage device. Besides, gpart is here and it works. And
in the future we'll have better tools for partitioning and disk setup.

> I'm still confused here.
> How can the desktop display the correct icons if HAL returns the wrong icons?
> I might be missing something.

HAL doesn't return icon names at all. The desktop UI figures out the name by
itself by inspecting the drive and media type. 

The ability for hal to return icon names is just only a hint to the desktop.
Also, if that property is used the icon name needs to be a lot more generic so
KDE and other desktops can theme it too. It's really just meant for storage
devices that are not common; e.g. phones, mp3 players and so forth.

> > So how do we move forward? I'm open for taking the ttyUSB and Firewire stuff.
> > Sounds good?
> 
> Ok.

I'll look into merging this. I'll keep the bug open until then.

(In reply to comment #10)
> (In reply to comment #9)
> > > Depends on the context. It's not impossible for me to imagine enterprise and
> > > government setups where they would care about this (a guard wouldn't allow you
> > > to move removable media outside a secure facility). Also things like SarBox.
> > 
> > This scenario looks quite a stretch, but I understand your position.
> > I agree with your NAK then.
> 
> It's a huge stretch, yeah. It's also about being secure out of the box. I can
> imagine tons of admins who would be caught by surprise. Including those running
> a Fedora box off a USB storage device. Besides, gpart is here and it works. And
> in the future we'll have better tools for partitioning and disk setup.

I'd agree that the case of running Fedora from a USB storage device is much more
compelling :)

> > I'm still confused here.
> > How can the desktop display the correct icons if HAL returns the wrong icons?
> > I might be missing something.
> 
> HAL doesn't return icon names at all. The desktop UI figures out the name by
> itself by inspecting the drive and media type. 
> 
> The ability for hal to return icon names is just only a hint to the desktop.
> Also, if that property is used the icon name needs to be a lot more generic so
> KDE and other desktops can theme it too. It's really just meant for storage
> devices that are not common; e.g. phones, mp3 players and so forth.

Ok.  I'll keep my local modifications then...

> > > So how do we move forward? I'm open for taking the ttyUSB and Firewire stuff.
> > > Sounds good?
> > 
> > Ok.
> 
> I'll look into merging this. I'll keep the bug open until then.

Ok.
I'll be looking for an updated package in the future...

Phil.

This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.