[sane-devel] Umask and xsane

[Olaf Meeuwissen]

Hi Richard,

Richard Ryniker writes:

> Olaf Meeuwissen <paddy-hack at member.fsf.org> wrote on Wed, 28 Aug 2019 20:18:26 +0900:
>
>   Any files created by XSane (or any SANE frontend or backend for
>   that matter) on behalf of the user should use the user's primary group,
>   IMNSHO, *and* honour the user's umask, no matter how odd.
>
> I agree about umask, but do not think SANE should contravene the system
> design and fifty years of history to create output files with unusual and
> unexpected characteristics.

My intent is to have XSane behave according to the principle of least
surprise.  Using the user's primary group and umask seems to fit that
bill.

> Consider a case where scanner acces is not a concern (perhaps a
> single-user system) but output files are to be shared, over a network,
> with others in an orgganization, some of whom may have their own scanners
> and create additional files to be shared.  If your group attribute scheme
> prevails, all these scanner users must be instructed that SANE behaves in
> an unexpected, non-standard way and they must use special procedures to
> "correct" the output file attributes to what they would normally be.

Point taken.  But now add the following compliation.  Users in that
organization use a variety of operating systems.  What guarantee does
XSane have that all of them use the same "scanner" group.

IIRC, SuSE put scanners in the "lp" group.  That may be unexpected and
non-standard but is not anything XSane can do about.

If those files should be shared from a certain directory by a bunch of
users in a certain group, then I guess the directory should be created
with 2770 (or more liberal) permissions with that group set and XSane
should honour the set-group-ID bit.  That is, it should not *force* the
user's primary group on the file.

So for my principle of least surprise goal, XSane should honour the
set-group-ID bit as well and let that override the user's primary
group.
Hmm, I guess that boils down to "Don't *enforce* a primary group".

If it does, it all comes down to where the user decides to save the
image file.  For XSane settings, these go someplace under $HOME and
should follow whatever has been set up for that location.

Checking on my own system, $HOME is 0755, $HOME/.sane is 0700 and so is
$HOME/.sane/xsane.  I *think* $HOME/.sane was created by XSane.  I
believe it should have created it with 0755 permissions (seeing that my
umask is 0022).  Ditto for $HOME/.sane/xsane.

For *my* system, I think XSane is overly paranoid.  Only if it creates
files with authentication credentials (I hope it doesn't and if it does
it should encrypt those credentials!) should it go about modifying the
umask to 0077 (especially so when *not* encrypting).  For anything else
it should leave it up to user's umask and file system settings.

> Your proposal may be exactly what many users desire, but it should be
> implemented as some option or configuration setting that explicitly tells
> SANE to act in this unusual way.

Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join