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

[m. allan noah]

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?

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