libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] [Patch] More bullet-proof drive detection for GNU/Li


From: R. Bernstein
Subject: Re: [Libcdio-devel] [Patch] More bullet-proof drive detection for GNU/Linux
Date: Tue, 28 Nov 2006 05:38:36 -0500

Burkhard Plaum writes:
 > Hi,
 > 
 > R. Bernstein wrote:
 > > I guess nothing based on /sys just yet.
 > 
 > No. It can be added later, but for older kernels (without /sys),
 > we need a fallback anyway. And since the current method should work
 > for *all* linuxes, I don't know if it's worth the effort to implement
 > something more advanced.

As a back-seat driver, here are my thoughts as to why /sys or
something like that is better. The problem with scan over a fixed
number of device numbers is that you never can get the number right:
either you are not scanning enough *and* on average the program is
scanning too much.

We received one comment that you really can't tell what the highest
SCSI device number would be. And right now it's set probably higher
than what most computers in fact have. So time spent in testing for
devices that don't exist on most computers, while still not being
thorough.

 > 
 > > Sorry for the late comment. I notice in cdio_follow_symlink() of
 > > lib/driver/util.c some strcpy's used. Isn't good security practice to
 > > use strncpy instead? Especially when one has the max length around
 > > (PATH_MAX, and/or len)?
 > 
 > The question is: Can we trust PATH_MAX? The destination arrays are
 > always PATH_MAX large, so an overflow occurs only if the src is larger than
 > PATH_MAX. But can this happen? 

Recommendation such as to use strncpy over strcpy is precisely because
the world has gotten so that you can't trust anything anymore: if
there's a way to subvert a program someone will make use of it.

Also, the "else" clause one has a length set which is less than
PATH_MAX.


 > If yes, than we should change strcpy to
 > strncpy, that's right. And then: Does PATH_MAX include the trailing '\0'?

I think this is up to the person writing a filesystem driver. A scan
of /usr/src/linux seems to indicate that some drivers don't try to put
in a trailing '\0' while some do. (But please double check me on this.)

 > If not, we should make the arrays one byte longer.

Probably a safe thing to do.

 > 
 > Burkhard
 > 
 > 
 > _______________________________________________
 > Libcdio-devel mailing list
 > address@hidden
 > http://lists.gnu.org/mailman/listinfo/libcdio-devel
 > 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]