OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Jeroen Dekkers (jeroendekkers.cx)
Date: Sat Jan 12 2002 - 09:04:23 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    On Sat, Jan 12, 2002 at 10:32:19AM +0200, Valentin Nechayev wrote:
    > Come to sinful land from your elephant bone towers. Your glibc isn't written
    > for you yourselves, or for another gurus; it is written for all.

    And that's the whole point. If there are a lot of people who think
    strlc*() is better and want to use it, IMHO glibc should provide them
    (maybe with a warning). It doesn't matter if you like them or not,
    other people like them and you should respect their opinion.

    > > I've examined only their first use (where strlcpy is used
    > > in a questionable way, and for all I know could be exploited by an
    > > attacker), and on their first use that is not questionable (where the
    > > strlcat calls are technically inferior to the standard alternatives).
    > > However, my brief impression from briefly looking at the "egrep"
    > > output is that these two examples are typical. If so, OpenSSH
    > > provides evidence against the use of strlcpy/strlcat.
    >
    > They are hardly nesessary in openssh. They are useful most elsewhere.

    The problem is that every function can be abused and you can make ugly
    code with every function. That's no reason for not including that
    function in glibc.

    > > > requires programmer to keep real buffer size in sight.
    > > That's the error in the approach. As written before, the GNU project
    > > recommends programs to avoid arbitrary limitations such as fixed-size
    > > buffers. So strlcat/cpy are contrary to the GNU way.
    >
    > Not all buffers are required to be of arbitrary size even with this approach.
    > Not all buffers are allowed to be of arbitrary size even with this approach.
    > Consider, e.g., buffer of outgoing NNTP command. One must not make
    > such command longer than 512 bytes, including terminating "\r\n".
    > There is no need to allocate million-byte string for NNTP command only
    > to check that it is too long; buffer of fixed size works here better.
    > Similarly, one must not overflow 1024-bytes path buffer, unless special
    > approach to reach longer path is used, as libtwonyeight implements.
    > There are many such examples.

    That 1024-byte path buffer is stupid and unportable. First why do you
    use a 1024-byte long buffer when the path is probably only 100 bytes
    long? That looks like a waste of resource to me, dynamic allocation is
    better.

    Second using a fixed-length buffer is wrong and hardcoding it to use
    1024 bytes is even more wrong. There are systems which don't have a
    limit on the path, the GNU system for example, because having a limit
    isn't required by POSIX and limits are just bad things (and in the
    Hurd I can easily think about paths longer than 1024 bytes).

    > And even when the case is ready for such GNU recommendation, not all programs
    > are of GNU. Unless you are Richard Stallman or his fanatical follower,
    > you don't consider glibc as environment only for GNU software.

    I can't speak for him, but I think even Richard Stallman doesn't
    consider glibc only for GNU software (else it was probably GPL'd and
    not LGPL'd).
     
    Jeroen Dekkers

    -- 
    Jabber supporter - http://www.jabber.org Jabber ID: jdekkersjabber.org
    Debian GNU supporter - http://www.debian.org http://www.gnu.org
    IRC: jeroenopenprojects
    

    -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org

    iD8DBQE8QFB3ZszgZglvGwcRApt4AKCoMEc975kisFooLBPxMVEirkEljQCgh36n wdDZuUrXofkSL1pwlZmCpis= =xi6a -----END PGP SIGNATURE-----