[sane-devel] [RFC] Locking devices via sanei_access lib...

[Gerhard Jaeger]

On Monday 07 February 2005 15:39, m. allan noah wrote:
> concerned about the security of well-known file names being used. i dont
> know all the implications and i did not read your code, but various
> symlink attacks might be possible. other apps deal with this of course,
> make sure to take a look at how they do it. also, is it possible to use
> flock() on the device files instead/as well?

Ah, I see. I didn't currently focus on security issues, but as far as I can
see using open with the correct permissions should help. Anyway
I'm open for further discussions on that and will do some more 
investigations. Eventually also flock() could be an option, I'll
check that.

Gerhard

>
> allan
>
> On Mon, 7 Feb 2005, Gerhard Jaeger wrote:
> > Hi,
> >
> > On Monday 07 February 2005 12:41, Johannes Meixner wrote:
> >> Hello,
> >>
> >> On Feb 7 12:11 Gerhard Jaeger wrote (shortened):
> >>> The idea is to provide a simple locking mechanism for the backends,
> >>> to have exclusive access to one scanner during an operation:
> >>
> >> ...
> >>
> >>> What do you guys think of this lib - is it useful?
> >>
> >> I even think exclusive access should be used by default
> >> because I think normally it doesn't make sense when there
> >> is more than one process which talks to the same scanner
> >> (i.e. "the same scanner" but not "the same backend" because
> >> one backend can drive several scanners).
> >
> > I agree! Each device a backend talks to needs some exclusive
> > locking!
> >
> >> Once it happened while I did a nice (you may say stupid) stress test
> >>
> >> for i in $( seq 100 )
> >> do sane-find-scanner & scanimage -L &
> >> done
> >>
> >> that one of my USB scanners made funny noise: It seems it tried
> >> to move its scanning unit beyond its physical limits.
> >> I have no idea how this could have happened but I guess the scanner
> >> was simply totally confused by the multiple concurrent accesses.
> >
> > It should not happen, but even such stupid tests show, that the locking
> > needs to be done in another way, as it's currently done, if it's done.
> > Rather the same "confusion" will happen when you have something
> > like Rene Rebes' button daemon which does nothing else than checking the
> > button status of a scanner - depending on the scanner, the backend needs
> > to check some or at least one register and when another frontend
> > currently is scanning - the scanner will not work properly afterwards
> > (highly depends on that device)
> >
> >> By the way:
> >> The reason for the above stress-test was that this way I could
> >> stop the kernel (no single error message in the logs  - just a
> >> sudden stop) - meanwhile I do no longer use the crap SCSI
> >> host adapter ;-)
> >
> > This test should become another stress-test for a new backend ;)
> >
> >
> > Ciao,
> > Gerhard
>
> --
> "so don't tell us it can't be done, putting down what you don't know.
> money isn't our god, integrity will free our souls" - Max Cavalera