[sane-devel] [Janitorial] Zero(!) compiler warnings
Olaf Meeuwissen
paddy-hack at member.fsf.org
Sat Sep 24 07:46:08 UTC 2016
ABC writes:
> On Thu, Sep 22, 2016 at 11:09:03PM +0900, Olaf Meeuwissen wrote:
>> > To what mktemp() should be replaced? Will there be sanei function to
>> > drop-in replace it?
>>
>> The mktemp(3) manual page suggests mkstemp (POSIX.1-2001, not in C99).
>> That is used by the bh and pieusb backends. You can also use tmpfile
>> (POSIX.1-2001, POSI.1-2008 and in C99), which is what I used in my patch
>> for the avision backend (not pushed yet).
>
> I feared that mkstemp and tmpfile are not available on all platforms
> supported by sane-backends.
In that case, maintainers of such platforms should speak up. I know
there are quite a few platforms that were supported at some point in
time but I have no idea what is still actively maintained and/or used.
The tmpfile() function is part of C99 which seems reasonably portable,
to me at least. FTR, we made that the default around the end of 2015,
beginning 2016.
>> I wasn't thinking of providing a sanei function for this.
>
> I think, if many libc authors wasn't able to design and implement good
> enough mktemp() from the first attempt, how is average sane contributor
> could be expected to do better? Just saying 'do not use mktemp' can
> produce even worse results (see below).
The problem with mktemp() is with its API specification. There's is
nothing you can do about that now. The C library implementers cannot
provide a secure mktemp(). To rectify that tmpfile() and mkstemp() were
added.
>> Note that mktemp() only creates a file*name* so the O_EXCL is not an
>> issue then and calling fopen() or open() isn't subject to this flag
>> unless passed explicitly. Child processes inherit non-exclusive open
>> file descriptors.
>
> Main security problem with mktemp is chance of opening precreated file,
> which impact could be mitigated with open() with O_EXCL flag. (Or
> fopen() with "x" flag, but I don't know how portable it's again.) In
> that regard, mktemp() can not be worse than opening static filename,
> like pieusb_specific.c, avision.c, canon630u-common.c, pnm.c,
> xerox_mfp.c are currently doing.
Opening a static filename may be just as bad, depending on how that name
is created and what that file is used for. But that is not something a
compiler or linker can warn about, unfortunately. For that we need to
rely on eagle eyes such as yours ;-) and the patches that produces.
# That is, personally I am mostly targetting the "low-hanging fruit",
# the kind of issues that can be detected by tools and fixed with not
# too much effort or knowledge of each specific backend. The mktemp()
# warnings actually require a bit of understanding of the backend in
# order to fix.
#
# I'm just the janitor. I'll look after the building (sane-project)
# but the tenants (backend maintainers) will have to look after their
# own rooms (backends).
Hope this helps,
--
Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Software https://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
More information about the sane-devel
mailing list