Not having a /var/run/console/console.lock sounds like the root cause.  What
does this say?:

grep pam_console /etc/pam.d/*

I get this:

/etc/pam.d/gdm:session    optional     pam_console.so
/etc/pam.d/gdm-autologin:session    optional     pam_console.so
/etc/pam.d/halt:auth       required     pam_console.so
/etc/pam.d/kbdrate:auth       required  pam_console.so
/etc/pam.d/login:session    optional    pam_console.so
/etc/pam.d/poweroff:auth       required pam_console.so
/etc/pam.d/reboot:auth       required   pam_console.so
/etc/pam.d/remote:session    optional   pam_console.so
/etc/pam.d/xserver:auth       required  pam_console.so

> What does this say?: "grep pam_console /etc/pam.d/*"

Exactly the same as in comment #1.

But I found that if I will log first on a console (after which
a correct /var/run/console/console.lock is present), followed
by a remote login from another machine, and now log out from a console
and re-log there as 'root' then /var/run/console/ is empty and
things which depend on PAM permissions are screwed regardles of
what how they were set in /etc/security/console.perms.  Quite
possible the same may happen with other login patterns but I
did not check.

This is actually a pretty frequent and "normal" scenario on my
test box and I imagine that it may naturally happen in "production".
I guess that an answer can be a very prominent warning in
RELEASE NOTES to the effect "do not ever log as root on a console
unless you are taking over the whole machine".

Sounds like a pam issue then.

This is exactly how the pam_console works - note the root login
doesn't manipulate the console.lock at all. For having console
ownership you have to be logged in on console. Remote logins don't
count at all.

> Remote logins don't count at all.

You are not paying attention.  In the situation described a local
root login on a console does exist.  This ends up with different
results from the situation when a non-root console login is used.
Nothing wrong with that as long as this is _prominently_ documented;
preferably in a few different places.  Or this is unintended and
unexpected side-effect?

Regardless of these details setting initial PAM defaults 600 for
scanner devices will surely result in people doing various
stupid things with that, like making everybody to run scans from
a root account, thus in practical terms sharply decreasing security.

Local root login on console does exist. But what do you expect
pam_console to do when only root login on console exist? And what
should be the difference from the situation where there is no console
login at all?

About the default permissions set on 600. You're right, reasonable
default would be to create a group 'scan', set the permissions to 660
with scan group ownership. You can certainly file it as enhancement
request on setup package.

Tomas: No, this is not how it should be done.  saned is there for
non-console logins.

Michal: I don't really understand how this relates to scanners.  If
you are logged on as root at the console, don't you already have the
priveleges you need?

> Michal: I don't really understand how this relates to scanners.

It seems that too many people look at Linux boxes as "single CPU/
single user" devices.  Even in my household, not mentioning a
business usage, this is not true.  If I want to set scanner
"0660, group scanner", or even "0666" when reasonable, then I would
like to see these permissions always regardles of who and how is
happen to be mucking around this moment with a console.  If this
cannot be ensured without hacking private copies of scripts then
I would like to see a prominent warning in docs which says what
to expect.

The fact that on my test box I logged as root and I have any
access to that scanner I want to is not here not there.  There are
_other_ users around who are using the same device even if they
are not logged on a console.

You are right that scanner is here only an example of a more
general problem although this happens to be a device with a
"naturally serializing" :-) usage patterns so too tight permissions
are really counterproductive.

I guess that a few intertwined issues are mentioned in this thread
and it is not always easy to untangle them from each other.

I do not think that NOTABUG designation is correct.

Michal, the permissions on the /proc/bus/usb/... nodes are set by
kernel. I don't know of any way how to set these permissions
permanently. The NOTABUG designation is correct and is about
pam_console not changing permissions for root login and about the
summary. Because normal login will affect permissions.

I think that you should consider setting up saned if you want to use
the scanner device in true multiuser environment.

> I don't know of any way how to set these permissions permanently.

Well, Tim and I do know such things. :-) Not permanently but
by PAM on every hotplug event and/or login.  Mind you, this
report was filed in a development branch.  A handler script
has just to add a link to a node in /proc/bus/usb/...  Indeed
the current attempt to do that suffers from bug #140259 but
this does not mean that this cannot be corrected and then
entries in /etc/security/console.perms govern access rights on
newly created nodes in /proc/bus/usb/...  If in such matters
you do have a list of cases which require a special handling
that is rather unsatisfactory for many reasons.  I hope that
this is evident.

The problem is that with a particular patterns of logins ****on
a console****,  while other logins are active as well,  this breaks
down in a surprising manner.  If you claim that this is no longer
surprising after a deep study of PAM sources, or even is mentioned
in some footnote somewhere in PAM documentation, then in practice
on real installations this is not good enough.  Hope that clarifies.

> Well, Tim and I do know such things. :-) Not permanently but
> by PAM on every hotplug event and/or login.
But this isn't permanently, is it? :-)

> If you claim that this is no longer
> surprising after a deep study of PAM sources,
No, not a deep study of PAM sources. What you are trying to do is to
abuse pam_console to do something different than it was designed for.
I don't say it's impossible to change it but I'm not sure it's the
best way.

Please attach your /etc/security/console.perms as you suppose it
should look like, then EXACTLY describe the scenario that you think is
broken. Note: Don't include remote logins to the scenario because they
are irrelevant to pam_console by definition.

> But this isn't permanently, is it? :-)

It cannot be permanently because underlying device nodes
in /proc/bus/usb/ are coming and going.  As more of such things
are getting "dynamic" you better get used to it.

> What you are trying to do is to
> abuse pam_console to do something different than it was designed for.

Well, not me, to be precise, but Tim.  And although we have
some differences of opinions about details he is IMO correct.
An end user cannot be told "if this is that kind of a device
then you are adjusting access controls here, but with another
kind that would be there and with still another one you have
to do something similar but different".

> EXACTLY describe the scenario that you think is broken

Ok, lets go again.  I have an USB scanner (a fairly common
device nowadays) and the following line in /etc/security/console.perms

<console>  0666 <scanner>

(yes, I know what I am doing and a scanner needs a write access
or it does not work; "revert" stuff is irrelevant as
there is no device node on a machine if that hardware is not
connected and powered up).

A hotplug script creates a link from somewhere in /dev to
a corresponding device node in /proc/bus/usb/ and PAM addjusts
permissions accordingly to an entry in 'console.perms'.  Let say,
to be concrete, the the "real" underlying device is
/proc/bus/usb/001/006 but this could be anything and it changes
when a hardware is powered down and up.

If I am logged on a console as 'michal' then
/proc/bus/usb/001/006 has permissions 0666, as desired.  If I
logout and log back on a console as 'root' then
/var/run/console/console.lock does not exist and if a scanner
would be powered only then then a corresponding device in
/proc/bus/usb/001/ it owned by root and has permissions 0644
(even if I would put in 'console.perms' 0600 or 0000).

Now I filed that originally as a bug in a corresponding hotplug
script but Tim claims that this is a PAM fault.  Who is right
here I do not particularly care but results are inconsistent
and surprising.  A read access on a scanner is irrelevant but
with some other device you man not want to have that only because
'root' is logged on a console.

> Don't include remote logins to the scenario because they are
> irrelevant

Actually they are very relevant.  I have other users which are
using that scanner logging remotely to a machine where the hardware
is hooked up.  With the above sometimes they can use scanner
and sometimes they don't - depending on what is happening on
some console over which they have no control.  Not mentioning
this detail that permissions are 0644 when nobody is logged in
so you can get a read rights on a flip of a power switch (which,
again, it may be "good enough" for some hotplugged devices).

If that all that would be _very prominently_ documented, with
huge warnings, then I can deal with that on a case-by-case basis
although this can be PITA in various situations.  As things are
right now this is a nasty surprise.

Thank you for your long comment. Now I know that I was right in my
previous comments.

I'll repeat this. The remote logins are irrelevant because they can't
and root login too because they can't affect pam_console by
definition. The root login must be ignored because it would break many
other now perfectly working scenarios where the machine is used as
one-regular-user-in-time with simultaneous root login for admin work.

-> There is no change in pam_console code which could help you and
didn't break anything.

So how about putting this in console.perms:

<console>  0666 <scanner> 0666

It would make sense wouldn't it? Because you just want the scanner
device to be rw for all all the time.

But it won't work because udev doesn't call pam_console_apply but
pam_console_setowner and only in case the console is owned by someone.
pam_console_setowner and the script which is it called from is owned
by udev so I'll reassign it.

Harald, please see my last comment.

Ah sorry, I take it back, the problem isn't in udev but in the
libusbscanner script. Instead of testing for console.lock and changing
the permissions on its own it should simply call pam_console_apply.

Tomas: What is pam_console_apply?  Could you provide an example?

I'm fed up of guessing with that script, and just want something that
works.

> Now I know that I was right in my previous comments.

Regardless if you were right or not there is a need for a way
to set scanner permissions for network logins too.  So far this
is difficult.

In other thread I pointed to, for example,

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121511#c59

so this is not only me pig-headed. :-)

Tim: pam_console_apply simply tries to reapply the permissions and
ownership on all devices depending on the console.lock. So if the
console.lock is there it applies all permissions as pam_console would
do on console login and if it isn't there it applies the permissions
as pam_console on logout.

The only cosmetic problem is that it reapplies the permissions on all
devices specified in console.perms, because there is no way how to
specify one device for it. This functionality could be added but I
think it isn't necessary.

There is pam_console_setowner from udev, which applies the ownership
to only one file using console.perms.

Yes I know, but the problem is it is usable only for setting the
permissions, not for resetting them. I think these two utilities
should be merged to one. I'll work on patch to pam_console_apply to
include the needed functionality.

Tomas: now that this is done, what change do I need to make in libusbscanner?

Created attachment 107615 [details]
Proposed libusbscanner script

I think it should look like this.

Thanks.