[sane-devel] SANE 1.1.0 Debug Levels
m. allan noah
kitno455 at gmail.com
Fri May 9 00:24:19 UTC 2008
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
> 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.
> > 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
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
> 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.
"The truth is an offense, but not a sin"
More information about the sane-devel