Discussion:
MODE="0664" versus MODE="0660"
Johannes Meixner
2007-08-07 09:43:06 UTC
Permalink
Hello,

right now I changed our Novell/Suse 55-hpmud.rules file from
SYSFS{idVendor}=="03f0", OWNER="root", GROUP="lp", MODE="0660"
to
SYSFS{idVendor}=="03f0", OWNER="root", GROUP="lp", MODE="0664"
(allow read permissions for HP USB device files for normal users).

Reason:
Without read permissions even a simple command like "lsusb" cannot
list HP USB devices to normal users which could cause unnecessary
confusion (e.g. when whatever GUI doesn't list HP USB devices).

But I wonder if such read permissions are sufficiently secure.
I assume they are because for retrieving data from the device
a matching request must be sent to the device which requires
write permissions.

On the other hand it might be possible that another normal user
can do eavesdropping while e.g. scanner data is sent from the
device to a user's scanning frontend.
I think that eavesdropping would be not possible if the hpmud
library opens the device file exclusively for its device I/O.

Therefore my questions:
Does the hpmud library open the device file exclusively or
is eavesdropping impossible because of whatever other reason?


Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
AG Nuernberg, HRB 16746, GF: Markus Rex

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
Suffield, David
2007-08-07 16:37:14 UTC
Permalink
Hi Johannes,

I believe MODE="0664" should be ok. HPLIP requires read/write access for
all device connectivity and exclusive access during printing, scanning
and faxing. So there should be no security risk with "other" users.
"other" users should not be able to snoop the scan data.

-dave
-----Original Message-----
Of Johannes Meixner
Sent: Tuesday, August 07, 2007 2:43 AM
Subject: [HPLIP-Devel] MODE="0664" versus MODE="0660"
Hello,
right now I changed our Novell/Suse 55-hpmud.rules file from
SYSFS{idVendor}=="03f0", OWNER="root", GROUP="lp", MODE="0660"
to
SYSFS{idVendor}=="03f0", OWNER="root", GROUP="lp", MODE="0664"
(allow read permissions for HP USB device files for normal users).
Without read permissions even a simple command like "lsusb"
cannot list HP USB devices to normal users which could cause
unnecessary confusion (e.g. when whatever GUI doesn't list HP
USB devices).
But I wonder if such read permissions are sufficiently secure.
I assume they are because for retrieving data from the device
a matching request must be sent to the device which requires
write permissions.
On the other hand it might be possible that another normal
user can do eavesdropping while e.g. scanner data is sent
from the device to a user's scanning frontend.
I think that eavesdropping would be not possible if the hpmud
library opens the device file exclusively for its device I/O.
Does the hpmud library open the device file exclusively or is
eavesdropping impossible because of whatever other reason?
Kind Regards
Johannes Meixner
--
SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany AG Nuernberg, HRB 16746, GF: Markus Rex
--------------------------------------------------------------
-----------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and
a browser.
Download your FREE copy of Splunk now >>
http://get.splunk.com/ _______________________________________________
HPLIP-Devel mailing list
https://lists.sourceforge.net/lists/listinfo/hplip-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/

Loading...