xsane as user

[Stefan Eßer]

On 2006-01-07 08:36 -0800, Arne Woerner <arne_woerner at yahoo.com> wrote:
> --- Stefan Eßer <se at FreeBSD.org> wrote:
> > > % cat /etc/devfs.conf 
> > > perm uscanner0 0664
> > 
> > Hmmm, why 0664?
> >
> Oh... I put myself into the operator group...

Yes, that's what I propose, too. Then 0660 is sufficient.

> I saw that too late... I hope my example still clear enough... It
> should have been 0666 there too.

That allows any user (i.e. any process on the system) to access the
scanner and thus documents on it. Depends on the confidentiality of
those documents whether that's acceptable ;-)

> > Interesting idea to apply devfs rules from
> > devd ...
> >
> I did not know, what devfs is good for, so I put it into devd so
> that it makes sense in my setting (when I unplugged the scanner
> the devfs settings were lost after I re-plugged the scanner).
> 
> > attach 100 {
> > 	device-name "uscanner[0-9]+";
> > 	action "chmod 660 /dev/$device-name";
> > };
> > 
> This creates uncontrolled redundancy, because then I have the
> perms set in devfs.conf and in devd.conf...

Correct. These two files serve different purposes, but there has
been some discussion about this topic recently.

As of now, devfs.conf is used to specify the initial state of the
device nodes created in /dev. When there was a /dev on the root
file system, ownership and permissions were persistent, and you
could have alias names for devices by creating symbolic links in
/dev.

To reconstruct a sane initial state (if the compiled in default
permissions are in the kernel are not considered appropriate), the
commands in devfs.conf are executed when going multi-user (via
/etc/rc.d/devfs).

> I haven't understood the devfs/devd idea completely... :-)

The devd process waits for changes in the device setup (e.g. when a
removable device is attached or detached) and executes the commands
specific to that device in devd.conf.

If the scanner is connected to a running system, there will be a new
uscanner device node (e.g. /dev/uscanner0), and devd can not only set
the permissions but could execute any arbitrary command with sensible
parameters (e.g. the device name can be passed).

Executing /etc/rc.d/devfs from within devd is possible, but may have
side effects (the initial settings are applied to all devices, though
some may have been modified in between and should not beb reset).
Besides, running this startup script is more effort than just calling
chmod with the device node as a parameter.

For that reason, the devd.conf line I sent in my previous mail does
just what's needed (adjusts the permissions) without the danger of
side effects on other devices and I'd suggest to switch over to using
it ;-)

Regards, STefan