Bug#405006: libgphoto2: mistake in udev rules gives permissions to non-gphoto2 devices

2007-01-17 Thread Nicolas George
L'octidi 28 nivôse, an CCXV, Frederic Peters a écrit :
> It doesn't set appropriate group for devices which are PTP cameras but
> not explicitely known by libgphoto2.

That would be a problem, indeed. I do not have any of those myself, so I can
not test. But I use the following rule for udev:

$ cat /etc/udev/rules.d/000_log.rules 
PROGRAM="/bin/sh -c '{ date; env; echo; } >> /dev/hotplug.log 2>&1'"

(having a log file in /dev is quite ugly, but it is the only filesystem that
I know will always be mounted read-write before udev starts doing its work)

With that, you can easily look if $INTERFACE is really what you expect it to
be.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature


Bug#405006: libgphoto2: mistake in udev rules gives permissions to non-gphoto2 devices

2007-01-17 Thread Nicolas George
L'octidi 28 nivôse, an CCXV, Frederic Peters a écrit :
> I believe things such as crypto USB devices would be affected by the
> bug.

I do not understand what you call a "crypto USB device". On the computer I
discovered the bug, I had write access to the raw devices corresponding to
the printer and the memory card reader.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature


Bug#405006: libgphoto2: mistake in udev rules gives permissions to non-gphoto2 devices

2007-01-17 Thread Nicolas George
L'octidi 28 nivôse, an CCXV, Steve Langasek a écrit :
> I'm actually fairly disinclined to accept this change for etch since as you
> mention it is a regression, and moreover I haven't heard anything back from
> the bug submitter about what actually gets broken on his system with this
> bug since it works for me.

I did answer to that, you probably missed it: if affects the raw USB devices
in /dev/bus/usb/, which can be used with lubusb.

By the way, I do not understand why Frederic Peters told that putting two
equal signs doesn't work: it seems to work fine here.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature


Bug#405006: libgphoto2: mistake in udev rules gives permissions to non-gphoto2 devices

2006-12-30 Thread Nicolas George
Le decadi 10 nivôse, an CCXV, Steve Langasek a écrit :
> Isn't the plugdev group empty by default?  This is obviously a bug, but I'm
> not sure it qualifies as a grave security bug.

The administrator is encouraged to add to this group users that need to
access cameras and similar devices. I believe this qualifies as a security
risk: users that had no access to some resources now can access them,
without the administrator knowing. The "grave" qualification is probably
exaggerated, but I was under the impression that all security bugs should
have it; maybe I was wrong; if so I am sorry.

> For that matter, with which devices are you seeing this problem?  After
> upgrading to this version of libgphoto2-2, plugging in a USB hard drive
> still gives me:
> 
> brw-rw 1 root disk 8, 0 2006-12-30 15:30 /dev/sda
> brw-rw 1 root disk 8, 1 2006-12-30 15:30 /dev/sda1
> 
> What class of USB devices are ending up under group plugdev that shouldn't?

It concerns the raw USB devices, in /dev/bus/usb/, used by libusb for
userland drivers. At the time where it was in /prob/bus/usb/, I believe only
devices with no kernel driver were available there, but it seems no longer
the case. In your example, you could probably have full access to the disk
using a userland mass-storage driver (there is such a thing floating around
on the web).

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature


Bug#405006: libgphoto2: mistake in udev rules gives permissions to non-gphoto2 devices

2006-12-30 Thread Nicolas George
Package: libgphoto2-2
Version: 2.2.1-12
Severity: grave
Tags: security

In /etc/udev/libgphoto2_generic_ptp_support.rules, there is the following
rule:

ACTION=="add", SUBSYSTEM=="usb_device", ENV{INTERFACE}="6/1/1", \
  PROGRAM="/bin/sh -c 'K=%k; K=$${K#usbdev}; printf bus/usb/%%03i/%%03i 
$${K.*} $${K#*.}'", \
  NAME="%c", MODE="0660", GROUP="plugdev"

The single = sign after ENV{INTERFACE} means that the INTERFACE environment
variable is set, not queried. The result is that all USB devices, and not
only the PTP ones, are set to the plugdev group, thus giving some users
access to devices they should not have access to.

Suggested fix: put two equals signs

Regards,

-- 
  Nicolas George


Irrelevant system information:

ii  adduser   3.100  
ii  libc6 2.3.6.ds1-8
ii  libexif12 0.6.13-5   
ii  libgphoto2-port0  2.2.1-12   
ii  libjpeg62 6b-13  
ii  libltdl3  1.5.22-4   
ii  udev  0.103-1
Linux hellroy 2.6.18-3-686 #1 SMP Mon Dec 4 16:41:14 UTC 2006 i686 GNU/Linux



signature.asc
Description: Digital signature


Bug#352575: display file:/// deletes its file

2006-02-13 Thread Nicolas George
Le quintidi 25 pluviôse, an CCXIV, Daniel Kobras a écrit :
> Are you aware of any applications that pass an URI to a mime handler
> rather than just the local path and filename? Furthermore, the mailcap
> entries in testing and unstable now prefix the filename with a format
> string based on the mime type, which makes it impossible to trigger this
> bug via the mime handler route.

I remembered in Gnome Control Center applications settings a checkbox "Can
open _URIs", but now that I look in the source, I see the code that takes
this checkbox into account is commented out. So I guess I can not give any
example, which is somehow a relief.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature


Bug#352575: display file:/// deletes its file

2006-02-12 Thread Nicolas George
Package: imagemagick
Version: 6:6.2.4.5-0.6
Severity: grave
Justification: user security hole
Tags: security

If display is called on a file:/// URL, it deletes the images after
displaying it. Steps to reprodude:

cp /some/image.jpg /tmp/test.jpg
display file:///tmp/test.jpg
Quit display: /tmp/test.jpg is gone.

Since display may be MIME handler for images, and configured to take URLs
and not paths, this may be a security risk in some cases.


-- (Probably useless) System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (50, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.14.1
Locale: LANG=C, LC_CTYPE=fr_FR (charmap=ISO-8859-1)

Versions of packages imagemagick depends on:
ii  libbz2-1.0 1.0.3-2   high-quality block-sorting file co
ii  libc6  2.3.5-13  GNU C Library: Shared libraries an
ii  libfreetype6   2.1.7-2.4 FreeType 2 font engine, shared lib
ii  libice66.9.0.dfsg.1-4Inter-Client Exchange library
ii  libjasper-1.701-1  1.701.0-2 The JasPer JPEG-2000 runtime libra
ii  libjpeg62  6b-11 The Independent JPEG Group's JPEG
ii  liblcms1   1.13-1Color management library
ii  libmagick9 6:6.2.4.5-0.6 Image manipulation library
ii  libpng12-0 1.2.8rel-5PNG library - runtime
ii  libsm6 6.9.0.dfsg.1-4X Window System Session Management
ii  libtiff4   3.7.4-1   Tag Image File Format (TIFF) libra
ii  libx11-6   6.9.0.dfsg.1-4X Window System protocol client li
ii  libxext6   6.9.0.dfsg.1-4X Window System miscellaneous exte
ii  libxml22.6.23.dfsg.1-0.1 GNOME XML library
ii  zlib1g 1:1.2.3-9 compression library - runtime


signature.asc
Description: Digital signature