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 > [email protected] > http://lists.gnu.org/mailman/listinfo/libcdio-devel > _______________________________________________ Libcdio-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/libcdio-devel
