Hello, On 2022-04-06 06:03, David Ward wrote (excerpts):
As suggested, soliciting comments on this issue: https://gitlab.com/sane-project/backends/-/issues/588
...
The user authorization handling in the net backend is insecure
...
I believe this handling in its current form should simply be removed. In an environment where user authorization is necessary, system administrators need to find their own way to support this that meets their requirements. Using an insecure solution built into SANE should not be provided as an option
I assume you are talking about /etc/sane.d/saned.users that - if exists - contains lines of the form user:password:backend to restrict access to a local SANE backend on a saned server for users who access this backend from remote clients there via their net backends via network and the saned on the server. First and foremost: I never used that myself and I never noticed a user question about it so I guess in practice it is perhaps not used or it is actually used and "just works OK for everybody" (but I doubt the latter is true ;-) I wonder if scanning frontend programs that are used on nowadays Linux desktops support a user password dialog when a /etc/sane.d/saned.users exists on a saned server? If nowadays (graphical) end-user scanning programs do not support /etc/sane.d/saned.users then I think it is probably best to drop support for it in SANE, ideally in a reasonably fail-safe way as described in https://gitlab.com/sane-project/backends/-/issues/588 In contrast when nowadays end-user scanning programs support /etc/sane.d/saned.users then I think even the current weak user authorization still has a valid purpose in particular within trusted internal networks. Reasoning: In network environments the admin should be able to set up rules what network scanners are available for the users so plain networking rules (e.g. based on IP addresses or so) can't provide that - those rules must be based on user IDs. In trusted internal networks such a setup does not need to be really secure. Assume in a trusted internal network there are two scanners and the admin does not want that one is accessible by all users of that network (e.g. one is reserved only for certain users). In a trusted internal network there is no need to setup strong security stuff for that. Just some simple thing is sufficient that denies unwanted user access. Of course it is only "security by obscurity" when an experienced user could still access something manually (e.g. via some hack or arbitrary self-written programs). Nevertheless I think in practice it makes a difference if any "unwanted" network scanner access would be "just possible for all users" versus when the user must do special actions to get access. There could be even a legal difference when prohibited access is "just possible" (even accidentally) versus when prohibited access is impossible by "usual means". FYI cf. my posting at https://github.com/apple/cups/issues/5011#issuecomment-304825279 Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Ivo Totev
