Make uname always safe
#1672
Make uname always safe
#1672
Conversation
Not specifically, but e.g. someone could set a non-UTF8 hostname with
Well, I see three possibilities here:
Converting the |
|
What if it returns an |
|
|
LGTM; can you squash and rebase? |
This fixes several issues with the current `uname` bindings:
- Do not ignore `uname` errors; at least on glibc `uname` can fail,
so now it returns a `Result` instead of assuming that the call
will always succeed.
- Do not assume `uname` will initialize every member of `utsname`;
not every implementation initializes every field, so internally
the struct is now zero-initialized.
- Do not blindly assume strings returned by `uname` will always be valid UTF-8;
`UtsName`'s accessors will now return `&OsStr`s instead of `&str`s.
Done! |
Currently
unamedoesn't check for errors and just blindly assumes that it always succeeds. According to the manpage this function can fail, even though no actual errors are defined:Looking at the glibc's sources we can see that it indeed could fail if the internal
gethostnamecall fails for some reason.This code also assumes that every field of
utsnameis going to be initialized by the call touname, which apparently is also not true. Even though the interface doesn't expose this field so it's not a problem in practice (although it might be UB since we do callassume_initon the whole struct) theutsnamedoes have adomainnamefield which glibc doesn't initialize.The code also assumes that every field is a valid UTF-8 string, which is also technically not guaranteed.
The code also assumes that every field will be null terminated, which might not be true if any of the strings are too long (since glibc uses
strncpywhich will not null-terminate the string if it ends up running out of space).This PR should fix all of these problems.
This is a breaking change.