[sane-devel] SANE 1.1.0 Debug Levels

[m. allan noah]

On 5/8/08, Olaf Meeuwissen <olaf.meeuwissen at avasys.jp> wrote:
> "m. allan noah" <kitno455 at gmail.com> writes:
>
>  > Ok- how about we start a separate thread for each major topic that
>  > needs discussing...
>  >
>  > Olaf has suggested that we split image data off into a different
>  > level. So I've gotten rid of the calibration level. These may not
>  > match what you guys need for your backends, so please make
>  > suggestions....
>
>
> Actually, the raw image data is just the most typical type of info
>  that would produce heaps of debugging data that is of virtually no
>  use when debugging.  Sending firmware files or calibration data are
>  others.
>
>  The idea is to have an alternative level for that kind of bulky
>  debugging data.
>
>
>  > 1 DBG_LVL_ERROR      (errors only)
>  > 2 DBG_LVL_WARNING  (recovered errors)
>
>
> You seem to imply the DBG_LVL_ERROR is for the unrecoverable errors.
>  If that is the case, I would think the user *always* wants to know or
>  *always* should be informed.  A level of zero might be appropriate.

IIRC the standard says that backends wont ouput anything unless they
are sane_open()ed? so you could have an 'always' on level, but it wont
quite fit in a mask :)


>  > 4 DBG_LVL_FUNCTION (function tracing 'enter xxx()' or 'exit xxx()')
>  > 8 DBG_LVL_DETAIL      ('trying action X' or 'action succeeded' etc)
>  > 16 DBG_LVL_OPTION   (any sane_option parsing code)
>
>
> Doesn't this correspond to DBG_LVL_DETAIL?  As in parsing option this,
>  setting option that, ...

yes, but i find in most backends i have ever looked at, that the
option parsing code generates significant amounts of noise, must like
image or calibration data.

>
>  > 32 DBG_LVL_COMMAND (dump data packets sent to scanner)
>  > 64 DBG_LVL_RESPONSE (dump data packets read from scanner, other than image)
>
>
> For my part, I would always want to see the pair of command and
>  response in the debug log, so I don't see the need to separate these.

fair enough.

>  > 128 DBG_LVL_IMAGE   (dump image data read from scanner)
>  >
>  > I have also been thinking about the security risk of those backends
>  > that open files and write out data at certain debug levels, how about
>  > we use a 9th bit for that, so that most users will never accidentally
>  > do it?
>
>
> IIRC, the debug level can only be set in a *portable* manner to a
>  value in the [0,127] range, ends inclusive.  This has something to do
>  with the way certain shells handle environment variables, but I don't
>  remember exactly where I got that idea.  I think somewhere in the GNU
>  Standards.

we could start using a quoted string instead of a number?

>
>  If that really is the case, bit fields for the levels are not a good
>  idea.
>
>  While you mention security risks, the image data might qualify in that
>  department.  Imagine the embarrasment if I were to send a debug log to
>  the list that included the image data for a page of the ESC/I spec ;-)
>
>  Users need to understand what is included in the debugging data that
>  they send you (or the list).

I did have a user once send me a test scan of the coverpage of a
secret corporate merger document, I knew both parties several weeks
before the market did :)

but, that not what i meant by security. some backends actually open
files on disk and start writing to them. all i need is to make a
symlink, and then convince the root user to do a debugging scan in my
homedir. typical, but admittedly rare file overwrite attack.

allan
-- 
"The truth is an offense, but not a sin"