readlink uses PATH_MAX-sized buffer, but PATH_MAX can't be relied upon

[SolraBizna]

The current nix implementation of readlink, which is a rather nice improvement over the previous version, is:

fn wrap_readlink_result(v: &mut Vec<u8>, res: ssize_t) -> Result<OsString> {
    match Errno::result(res) {
        Err(err) => Err(err),
        Ok(len) => {
            unsafe { v.set_len(len as usize) }
            Ok(OsString::from_vec(v.to_vec()))
        }
    }
}

pub fn readlink<P: ?Sized + NixPath>(path: &P) -> Result<OsString> {
    let mut v = Vec::with_capacity(libc::PATH_MAX as usize);
    let res = path.with_nix_path(|cstr| {
        unsafe { libc::readlink(cstr.as_ptr(), v.as_mut_ptr() as *mut c_char, v.capacity() as size_t) }
    })?;

    wrap_readlink_result(&mut v, res)
}

The Linux man page for readlink has this to say:

Using a statically sized buffer might not provide enough room for the symbolic link contents. The required size for the buffer can be obtained from the stat.st_size value returned by a call to lstat(2) on the link. ... Dynamically allocating the buffer for readlink() and readlinkat() also addresses a common portability problem when using PATH_MAX for the buffer size, as this constant is not guaranteed to be defined per POSIX if the system does not have such limit.

Per the above, the fixed-size buffer should be replaced by one of the following approaches:

• Use lstat to read the size of the link, allocate a buffer that large plus one, readlink. If the return value isn't exactly v.capacity()-1, start over. (An approach like this is recommended in the Linux manpage, but supposedly some filesystems' stat implementations report a size of zero bytes for all symlinks, so...)
• Starting with a reasonable minimum size (PATH_MAX.max(128) or something?) and increasing each time, repeatedly readlink until the returned size is strictly less than the buffer size. (maybe fall back to this if lstat returns zero size?)

Also, we should probably guard against readlink returning a size larger than the buffer. I don't know of any actual UNIXoid that does this, but... this is Rust after all.

I would take a crack at this myself, but I'm still recovering from some nastiness. Just composing this issue took me six hours, drifting in and out of dizzy semi-consciousness. Not the best state to write important code in.

[asomers]

So POSIX doesn't require PATH_MAX to be defined if the system has no such limit. But if it is defined, does that mean it's guaranteed to work?

[SolraBizna]

Well, IIRC PATH_MAX is 1024 on Linux, but just now I was able to create 10,000 nested directories named "test" and everything still seemed to work.

[asomers]

uggh. What's PATH_MAX for, then? Very well, let's try the stat-based approach. Perhaps fall back to the other approach if stat reports a length of 0?

[Artoria2e5]

PATH_MAX is pretty much just an arbitrary limit in old-school Unix so some of the APIs can have a non-infinite max size. See https://eklitzke.org/path-max-is-tricky.

[asomers]

@SolraBizna do you still want to take a crack at fixing this?

[SolraBizna]

I'll give it a shot tomorrow.

[SUPERCILEX]

@asomers Pretty sure this should have been closed by #1231

[SolraBizna]

Oh, neat, I can close it as completed. Guess I should've done that a while ago. 🙂