OpenBSD Journal

getcwd reliability patch available

Contributed by jcs on from the patch-and-make-and-make-install dept.

Quoting errata.html:

008: RELIABILITY FIX: January 6, 2005
The getcwd(3) library function contains a memory management error, which causes failure to retrieve the current working directory if the path is very long.

The patch is available from your local FTP mirror.

(Comments are closed)


Comments
  1. By almeida (192.160.62.60) on

    I just applied 008_getcwd.patch and rebuilt and installed libc. The patch instructions tell me I need to rebuild statically linked binaries before they'll pick up the changes:

          Note that programs that are linked statically will not pick up the
          change unless they are rebuilt.  This includes the contents of /bin
          and /sbin.  The following static binaries use getcwd(3):
              /bin/csh, /bin/ksh, /bin/pwd, /bin/systrace, /sbin/dump
    

    Is this the proper way to rebuild csh, for example?

    # cd /usr/src/bin/csh
    # make obj cleandir depend
    # make && make install
    

    Also, is there a way to determine what other static binaries also use getcwd?

    Comments
    1. By jose (204.181.64.2) on http://monkey.org/~jose/

      this is one method to get at least a partial list:
      for i in `grep -l getcwd /usr/*bin/* /bin/* /sbin/* /usr/local/*bin/*`; do
          file $i
      done | grep -v dynamically
      
      hope this helps.

      Comments
      1. By Andreas (134.100.120.75) on

        I used the following snippet :
        for i in /bin/* /sbin/* /usr/bin/* /usr/sbin/* /usr/libexec/* /usr/mdec/* /usr/games/* /usr/X11R6/bin/* ; do
          file $i | egrep statically >/dev/null && strings $i | egrep getcwd | egrep -v OpenBSD && echo $i
        done
        
        This snippet, however, misses the shells (?), OTOH it found /usr/bin/ftp as another static binary using getcwd. /usr/bin/kdump may be another candidate.

        To the grand-parent : that's what I did.

        Comments
        1. By Otto Moerbeek (82.197.192.49) otto@drijf.net on http://www.drijf.net

          If youy use something like
          ident $i | grep getcwd.c
          
          instead of grep on the executable you will get more reliable results.

          Some program do not use getcwd(3) directly, but via another library function like realpath(3).

          Comments
          1. By Otto Moerbeek (82.197.192.49) otto@drijf.net on http://www.drijf.net

            Oops, I'm afraid I was not very clear in my prevous message. I think the following script should do it:
            for i in /bin/* /sbin/* /usr/bin/* /usr/sbin/*; do
            if file $i | grep statically > /dev/null; then
                    (ident $i | grep -q getcwd.c) && echo $i
            fi
            done
            

            Comments
            1. By almeida (192.160.62.60) on

              Thanks jose, Andreas, and Otto. There are quite a few things that use getcwd. This is what Otto's script picked up on my box:
              /bin/csh
              /bin/ksh
              /bin/mv
              /bin/pwd
              /bin/rksh
              /bin/sh
              /bin/systrace
              /sbin/dump
              /sbin/mount
              /sbin/mount_ados
              /sbin/mount_cd9660
              /sbin/mount_ext2fs
              /sbin/mount_fdesc
              /sbin/mount_ffs
              /sbin/mount_kernfs
              /sbin/mount_msdos
              /sbin/mount_nfs
              /sbin/mount_ntfs
              /sbin/mount_null
              /sbin/mount_portal
              /sbin/mount_procfs
              /sbin/mount_umap
              /sbin/mount_union
              /sbin/mount_xfs
              /sbin/mountd
              /sbin/rdump
              /sbin/umount
              /usr/bin/ftp
              

    2. By Anonymous Coward (146.186.107.112) on

      Unless I miss something but nobody answered his first question: Is this the proper way to rebuild csh, for example? # cd /usr/src/bin/csh # make obj cleandir depend # make && make install Should I rebuild static binaries, which use getcwd, as well?

      Comments
      1. By Anonymous Coward (69.182.25.166) on

        I think you can just do this:

        # cd /usr/src/bin/csh
        # make clean all install

  2. By Brian (205.161.1.46) on

    Whats the impact of this bug? Who should patch?

    Comments
    1. By tedu (67.124.88.142) on

      Whats the impact of this bug?

      failure to retrieve the current working directory if the path is very long.

      Who should patch?

      you

      Comments
      1. By Brian (205.161.1.46) on

        > failure to retrieve the current working directory if the path is very long.

        Yes, I can read read. I didn't know the impact when I read that statement in the advisory and I still dont know it after reading it from you. I doubt many non-developers would know either.

        I usually don't apply non-security fixes unless I know that they affect me, especially ones that require me to recompile much of /sbin and /bin.

        Comments
        1. By Otto Moerbeek (82.197.192.49) otto@drijf.net on http://www.drijf.net

          Erratas are made for problems we consider critical. So unless you know for sure the errata does not apply to you and will not apply in the future, you should patch.

          Erratas are derived from the -stable branches. We have strict rules for introducing fixes into these branches. We are extra careful not to break other things while fixing a problem. So your hesitance to apply patches is not really appropriate.

          It is so much easier to say: this machine has all erratas applied, compared to: this machine has errata x, y and z applied, but now its usage pattern has changed and I forgat about checking if the set of relevant patches is still the same.

          Comments
          1. By Brian (205.161.1.46) on

            A lot of the errata seems to be critical for a few users, but not the vast majority. Its nice to have everything patched, but patching (esp in this case) can be quite time consuming. It's hard to justify spending an hour patching for something that either can't be malicously exploited or you are extremely unlikely to run into. The lynx and xl errata for 3.6 are good examples of bugs I didn't patch on my machines. I don't think I've used either for at least four years, and I've never used xl on the platform the advisory states is affected.

            Most of the one or two line advisories either state who would be affected by the bug or include enough information for a non-developer (well, me) to know how they're affected. I don't know from this one, so I asked. I think it was a very relevant question, but apparently it appeared to be a troll.

            Comments
            1. By Otto Moerbeek (213.84.84.111) otto@drijf.net on http://www.drijf.net

              Again, you should assume you are affected unless you know for sure you are not.

              The patch concerns a library function. A lot of programs use this library function. Furthermore, the errata does not specify a specific group of users. Conclusion: you should assume you are affected.

        2. By tedu (64.173.147.27) on

          how do you expect me to know if you have very long paths on your machine?

    2. By Shabani (65.94.172.111) on

      While downloading this patch from http://gulus.usherb.ca, I saw a new one (009_httpd.patch) dated January 10. Yet, it doesn't appear on OpenBSD website. Is this some kind of joke ?

      Comments
      1. By Brad (65.110.162.62) brad at comstyle dot com on

        No, it is not a joke.

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]