Issue with resolving paths with zsh using \0 in variables

Issue with resolving paths with zsh using \0 in variables

[Branden Archer]

[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]

This is an issue found when attempting to use paths in zsh where parts of
the path are taken from data on the /sys filesystem. Namely, when cat'ing a
file from the /sys filesystem it may return some data with a \0 at the end.
If that variable is used to form a path the \0 interferes with the path
resolution. Here is an example of this:


root~# echo $ZSH_VERSION
5.3.1
root~# mkdir subdir
root~#
root~# printf "dir\0" > location
root~# touch subdir/myfile
root~# echo "hi" > sub$(cat location)/myfile
zsh: is a directory: subdir
root~# echo "hi" > subdir/myfile


It was found on bash that this did work, so it is believed that this is a
valid use case. Namely, on bash the \0 at the end of the data returned
from $(cat
location) is ignored.

There is a workaround for this, which is to use realpath on the directory
then use the result to access the file:


root~# complete=$(realpath sub$(cat location))
realpath: : No such file or directory
# ^ from stderr
root~# echo "hi" > ${complete}/myfile


However, it would be nicer if that workaround was not necessary.

If you have any questions about this issue, let me know. Thanks!

- Branden

Re: Issue with resolving paths with zsh using \0 in variables

[Eric Cook]

On 06/13/2017 03:32 PM, Branden Archer wrote:
> This is an issue found when attempting to use paths in zsh where parts of
> the path are taken from data on the /sys filesystem. Namely, when cat'ing a
> file from the /sys filesystem it may return some data with a \0 at the end.
> If that variable is used to form a path the \0 interferes with the path
> resolution. Here is an example of this:
> 
> 
> root~# echo $ZSH_VERSION
> 5.3.1
> root~# mkdir subdir
> root~#
> root~# printf "dir\0" > location
> root~# touch subdir/myfile
> root~# echo "hi" > sub$(cat location)/myfile
> zsh: is a directory: subdir
> root~# echo "hi" > subdir/myfile
> 
> 
> It was found on bash that this did work, so it is believed that this is a
> valid use case. Namely, on bash the \0 at the end of the data returned
> from $(cat
> location) is ignored.


Silently mangling input isn't a valid usecase, even recently in
bash there is an warning that is displayed when it happens.

http://lists.gnu.org/archive/html/bug-bash/2017-04/msg00016.html

Re: Issue with resolving paths with zsh using \0 in variables

[Bart Schaefer]

On Jun 13,  3:32pm, Branden Archer wrote:
}
} This is an issue found when attempting to use paths in zsh where
} parts of the path are taken from data on the /sys filesystem. Namely,
} when cat'ing a file from the /sys filesystem it may return some data
} with a \0 at the end. If that variable is used to form a path the \0
} interferes with the path resolution.

I believe this is because zsh supports having nul-bytes in parameter
values, whereas bash treats the nul as terminating the string.  This
is not something we can (or I think want) to special-case for file
paths.

Those files in /sys are documented to contain strings separated by
nul bytes, so as soon as you read one with "cat" you have already
made a coding error.  Instead you should be doing something like

    read -d $'\0' -E < location

Conversely, this --

} root~# echo "hi" > sub$(cat location)/myfile
} zsh: is a directory: subdir

-- probably is a bug, just not the bug you think it is; the error should
be that "subdir\0" is an illegal file name, rather than terminating the
path at the nul and botching the redirection.

Re: Issue with resolving paths with zsh using \0 in variables

[Eric Cook]

On 06/14/2017 07:02 PM, Bart Schaefer wrote:

> -- probably is a bug, just not the bug you think it is; the error should
> be that "subdir\0" is an illegal file name, rather than terminating the
> path at the nul and botching the redirection.
> 

I think it is correct, since \0 is in IFS, word splitting happens since the command substitution
isn't quoted. Since zsh will sent the output of a command to multiple destinations if the result
of an expansion is multiple words, it zsh tries to send the output to dir/ and /myfile; but
fails hard when it can't write to dir/, not attempting to write to /myfile.

When the expansion is quoted, you do get the error that you think it should have.

Re: Issue with resolving paths with zsh using \0 in variables

[Bart Schaefer]

On Jun 14, 11:40pm, Eric Cook wrote:
}
} On 06/14/2017 07:02 PM, Bart Schaefer wrote:
} 
} > -- probably is a bug, just not the bug you think it is; the error should
} > be that "subdir\0" is an illegal file name, rather than terminating the
} > path at the nul and botching the redirection.
}
} When the expansion is quoted, you do get the error that you think it
} should have.

No, I don't:

torch% echo "hi" > "sub$(cat location)/myfile"
zsh: is a directory: subdir^@/myfile

Re: Issue with resolving paths with zsh using \0 in variables

[Bart Schaefer]

On Jun 14, 11:40pm, Eric Cook wrote:
}
} ... since \0 is in IFS, word splitting happens since the command
} substitution isn't quoted.

This is happening, though, I didn't mean to imply otherwise.

} zsh tries to send the output to [subdir] and /myfile; but fails hard when
} it can't write to [subdir], not attempting to write to /myfile.

This bothers me a little bit as well, actually, though probably there
is nothing to be done about it, since there's no way to validate all
the attempted redirections at once.