Bug 140259

Thanks for the report.  The reason that the script waits for /dev/usb to appear
is to be sure that devfs is mounted.  There needs to be a more robust method for
this, since /dev/usb may not be created in the /dev filesystem.

Does sane-backends-1.0.15-4 behave any better?  It's just a 30s time-out at the
moment until someone suggests the right way to do it.

Looping for 30 seconds will not help very much if you do not have
/dev/usb.  Why you will not just make that link in /dev which is
not likely to go unexpectedly? :-)  This is the same from the point
of view of PAM and does not collide with anything (and you can
make names like /dev/scanner-usb-.... as long as they match
"scanner*" pattern).  Or you do that now?  I did not have a chance
yet to look at 1.0.15-4.

See comment #1: I want this to work on devfs systems too.  I meant to add a
mkdir if it timed out (but forgot - oops).

Add both links then.  Would that make any harm on devfs?  And I would
loop waiting for a file system to show up in a background and
separately.  Making a scanner unusable for the first 30 seconds after
it was turned on because of devfs, while the system happens to use
udev, does not strike me as acceptable.  Users will decide long before
that that this is broken. 3 second wait maybe would be passable
but it already seems to be on the border (it will be "hidden"
in a scanner warming-up).

I may make up some code later if needed (although I am not sure
if I really understand devfs problem).

Two things:

* the reason we wait for /dev/usb to show up is that we want to avoid a
filesystem being mounted on top of the directory we just planted a symlink in;
otherwise it will not be visible to pam_console later on.

* I don't believe that a 30s delay will be noticeable, because in the cold-plug
case you have to actually log in and start up a scanner application during that
time, while in the hot-plug case the permission change is done there and then
(the 30s delay applies only to the creation of the symlink).

That said, I *know* that waiting for 30s is not the final solution.  I'm waiting
for input from someone who can shed light on what that final solution should be.

So, infinite loop made finite, this bug is now starting to wander into the realm
of bug #121511..

> we want to avoid a filesystem being mounted on top of the directory
> we just planted a symlink in;

That is why I suggested to make that link in /dev instead of /dev/usb.
I still do not understand what is wrong with that (but I am not
really familiar with requirements of devfs).  If you will make
two links, one if /dev and another in /dev/usb if needed, pointing
to the same node in /proc/bus/usb/..., and waiting separately and
independently, then PAM will adjust permissions no matter what.
Yes, the one in /dev/usb may show up later or never - if /dev/usb
does not exist.  So what?

You want the above if a link in /dev/usb is _really_ required
in some setups.

> I don't believe that a 30s delay will be noticeable

It will be very noticeable.  A common scenario: you are already
logged on and you are pushing a power button on a scanner machine
and starting xsane.  Immediately you are greeted with an alert
"no scanner devices available", or something like that,  _unless_
(and this is a very dangerious part security-wise) you are "root".
This is really a way in which xsane tells you that it does not have
write permissions to access that scanner as read only are not
good enough.  These permissions will show up after some 30 seconds,
which is way too late, but a user concluded a long time ago that
things are plain broken.

I am not making that up.  I already have seen that "in the field".

> These permissions will show up after some 30 seconds

*sigh*

I'll write it here again, in case you read it all this time:

* I don't believe that a 30s delay will be noticeable, because in the cold-plug
case you have to actually log in and start up a scanner application during that
time, while in the hot-plug case the permission change is done there and then
(the 30s delay applies only to the creation of the symlink).

*sigh again*

> I don't believe that a 30s delay will be noticeable, because
> in the cold-plug case you have to actually log in and start up
> a scanner application during that time,

If a scanner was already plugged in and powered up then you
are right.  None of these is even remotely reasonable to
always assume; especially in cases of USB scanners.

> while in the hot-plug  case the permission change is done there

Nope!  If a scanner was not powered up then a node in
/proc/bus/usb/ does not even exist so it is hard to create a
link to it not mention even permission changes.

> ... and then (the 30s delay applies only to the creation of the
symlink).

Which starts when you hit a power button and/or plugged the
thing already powered and this may be a long way past after
you logged in.  Actually usually it is if that piece of a
hardware is not in a constant use.  This is a very common and
natural usage pattern.

Do you have such scanner somewhere around?  Did you try to see
how it is used in the real world?

Could you explain what is really wrong in creating a symlink
directly under /dev which would avoid that whole rigmarole?
How devfs is adversely affected by that?  You may need to be
careful but only during a startup not to do anything before
the final /dev is, possibly, mounted.  Later you do not have to
wait for anything.

> ... when you hit a power button
I meant above a power button on a scanner machine - in case this was
not clear from the context.

> > while in the hot-plug  case the permission change is done there
> Nope!  If a scanner was not powered up then a node in
> /proc/bus/usb/ does not even exist so it is hard to create a
> link to it not mention even permission changes.

You switch on the scanner and hotplug runs libusbscanner which sets
the permissions -- or not?

No, the scanner I have access to is hpoj-driven.

Moving the link to /dev doesn't make any difference.  If devfs is in
use and we don't wait for it, it will be mounted on top of /dev,
hiding the symlink from view.

Please add further comments to bug #121511.

> You switch on the scanner and hotplug runs libusbscanner which sets
> the permissions -- or not?

It does, after various bits and pieces are fixed, but if you are
using the current setup with 'udev' where /dev/usb does NOT exist,
it does that only after 30 seconds delay.  That is why it went in
an infinite loop in the first place. Remember?  True, once you added
that it should stay but after every reboot a scanner is "broken"
initially unless you did some special ministrations.

> If devfs is in use and we don't wait for it, it will be
> mounted on top of /dev

OK.  So we are waiting for /dev/usb too late and in a wrong
place.  Arrange with 'udev' guys to make /dev/usb/ and/or wait
for it in a startup.  Once it is in place then 'libusbscanner'
will not wait for it 30 seconds, unless something will remove
it, so that delay will not kick in.  You may still keep a
sanity check in 'libusbscanner', just in case, but it should
never trigger even in a situation when, while already logged,
you just brought a scanner, plugged that in and pushed a power
button.

If you have in a startup a safe place where you can wait for
/dev/usb, and create it if it still not there after a suitable
delay, then do this in a background so the rest of a startup may
proceed in the meantime.

> It does, after various bits and pieces are fixed, but if you are
> using the current setup with 'udev' where /dev/usb does NOT exist,
> it does that only after 30 seconds delay.

??

The script does this:

find out console user
if console user:
  set permissions for them

wait for /dev/usb to exist
make a symlink there

Anyway: PLEASE put comments in bug #121511!

> ??
....
> wait for /dev/usb to exist

Exactly!  You booted and /dev/usb does not exist.  Try on the
current "devel", for example, without any extra additions.

$ ls /dev/usb
ls: /dev/usb: No such file or directory

Now you are powering up scanner and you have to be patient
enough to wait for 30+ seconds for (corrected) libusbscanner to
time-out.  Most people decided a long time ago that something
is broken.  What is here not to understand?  If you created
/dev/usb/ at this point then the next time there is no problem
but we are not talking about "the next time".

You expect that scanner was on when you were booting?  Not very
likely with a USB device unless it is in a constant use and does
not help that much as 'libusbscanner' may not run there anyway
(and you do not want to add extra over 30 seconds of an idle time
to a startup).

> Anyway: PLEASE put comments in bug #121511!

This was about the current implementation in "devel" but ok,
with anything more I will go back to bug #121511.

I'm completely failing to grasp what you're saying, so you're going to
have to explain it for me slowly.  Immediately before the line you
quote was:

if console user:
  set permissions for them

Why is that not working for you when you plug in a scanner after
having logged in at the console?

> so you're going to have to explain it for me slowly

See, for example, the second paragraph in 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121511#c59

Ok, let walk that step by step:

1. find out console user
2. if console user:
3.   set permissions for them

4. wait for /dev/usb to exist
5. make a symlink there

re 1.  'root' is, apparently, no console user (as also a situation
where nobody is logged in on a console but lets leave that out for
the moment)
re 3.  a USB scanner is not on yet so there is nothing on which
we can set permissions
re 4.  somebody just logged on from their workstation on a box
with a scanner and hit a power button on a scanner as they want
to do some scans; /dev/usb does not exist so far so we have a 30
seconds wait (actually a bit longer due to a loop overhead; I would
probably write is somehow like 'for in $(seq 30); do ...;done' but
these are details); if /dev/usb/ would be "precreated" in a startup
when needed then this wait would not exist.
re 5.  a link was finaly created and PAM adjusted (or not, depending
on what was happening on a console) permissions on a scanner according
to specs in 'console.perms' and a scanner is finally available; that
link really serves only this purpose so if you do not care about PAM
there is no point in the later part of the script and you could
operate on /proc/usb/bus/ entries directly as before.

> Why is that not working for you

It is not a question of working only for me but for everybody
around.  There is some, but essential, difference.  Yes, I can
hack my own variant of libusbscanner, which avoids problems and
which is clobbered by every update (ugh!) but this is not the
point here.  Apparently due to how PAM works I will have to do
that anyway.  It starts to look  that instead of hardwiring some
permission in 'libusbscanner' that script should have a config file
where one could set an optional group and access rights and leave
all that PAM business alone.

Version sane-backends-1.0.15-7 includes what looks like a workable
/etc/hotplug/usb/libusbscanner script.  Some results of changes
in /etc/security/console.perms can be a bit unexpected but the
important thing is that one can actually achieve desired ownership
and permissions by adjusting entries in that file.

A small cosmetic issue.  A comment in 'libusbscanner' says
"Make a symlink from /dev/usb-scanner-BBB:DDD ..." while in reality
a symlink called "/dev/scanner-usb-:proc:bus:usb:BBB:DDD" shows
up (which is good as it corresponds to existing patterns in
'console.perms').

Thanks, fixed in CVS.

The important question is: does it work?

> The important question is: does it work

As I wrote "one can achieve". :-) A bit of a surprise was that
these were "revert" settings in /etc/security/console.perms
which turned out to be essential in the context but with some
adjustments there one can get permissions automagically set
as desired.

Even when I boot with a scanner already turned on I end up with
expected settings.

I still think that adding a predefined group "scanner", similar
to those like "disk" or "floppy", would be a good idea. A post
script in 'sane-backends' package could take care of that together
with a corresponding adjustment in rules from 'console.perms'.

No, it should work as a console device.

I take it that's a "no it doesn't work" then.  Can you confirm please?  It is
*intended* to just work, so if it doesn't then it needs further changes.

> I take it that's a "no it doesn't work" then.

I am not sure why. Rules who is a "console owner" are somewhat
baroque in places and after a closer look one or another set
of permissions applies depending on who is logged in and from
where.

One thing which "does not work" is that when I will boot with
a scanner turned on then a link /dev/scanner-usb-* is created
but turning scanner off is not removing it.  I do not really
see so far why this happens. Later links show up
and disappear on a flip of a power switch but that first
one lingers and points to a location which ceased to exist.
I am not sure if there is a scenario when /proc/usb/bus/...
entry can be reused, possibly for something else, and this
may be a problem (apart of beeing unsightly).  Maybe after
a reboot with /dev mounted from some permanent storage?

The newer hotplug package is meant to fix that I think.  Which version of
hotplug have you got?

> Which version of hotplug have you got?
hotplug-2004_04_01-10.  So far this looks like the latest one
in rawhide.