Re: bin/55815: tar opens device files

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR bin/55815; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/55815: tar opens device files
Date: Mon, 7 Jun 2021 02:36:45 +0000

 On Sat, Jun 05, 2021 at 08:25:01PM +0000, Joerg Sonnenberger wrote:
  >>  Isn't the point here to prevent tar from opening device files?
  >  
  >  If the opening with O_REGULAR fails, you are already in the side path
  >  for objects you don't want to open. Fifos, Unix sockets, devices. This
  >  whole discussion shouldn't be about tar either. The whole "open has side
  >  effects" problem applies to many, many other programs, so it should
  >  really be considered in this wider context... 
 
 It also isn't necessary to mine the moon if all you're after is some
 rock.
 
 The proper logic is
 
    lstat
    if (ISBLK || ISCHR) {
       acl_get_link()
    }
    else if (ISLNK) {
       acl_get_link()
       readlink()
    }
    else {
       fd = open(O_NOFOLLOW|O_NONBLOCK)
       if (fd < 0) {
          goto retry;
       }
       fstat(fd)
       acl_get_fd(fd)
    }
 
 If doing this on a live system, the object can get shuffled between
 the lstat and the acl_get_link/readlink calls, but:
    - I assume tar is using single-layer names and not long paths, as
      in the latter case all these worries are trivial by comparison;
    - only root can shuffle device nodes, so there's no exploit path
      there;
    - anyone can mess with symlinks, but that's not a new problem and
      nothing related to devices affects it;
    - you _can_ check if the object you opened was the same as the
      object lstat inspected, but there's no point; just ignore the
      lstat results completely and proceed;
    - O_NONBLOCK is sufficient to make named pipes safe.
 
 I don't see what the problem is or why we're going around in circles
 about it.
 
 Yeah, it might be nice to have a way to open an object for O_NONE or
 something (so you get a fd but all you can do with it is what you
 could do via its name) but it's not necessary to fix this problem.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost