The Story of a Rust Bug | Hacker News Reader

The Story of a Rust Bug

thesquareplanet.com

140 pointsJonhoo16 comments

This is a bug in glibc[1] more than it's a bug in Rust.

[1]: https://sourceware.org/bugzilla/show_bug.cgi?id=984 ; from the Reddit thread kibwen linked to[2]

[2]: https://news.ycombinator.com/item?id=14324331

It is sad that bug has been open for so long.

It seems like it would be better to have some kind of dns proxy daemon running that libc talks to that can pick up these changes immediately but I guess that is out of the scope of libc :)

One can argue that maybe networking functions shouldn't be part of the C standard library, but maybe a hypothetical "libos" instead, sort of like how Rust has libcore, libcollections, liballoc, and libstd separated.

I wonder if modularizing libc is at all feasible. Linux lets you use multiple libcs, so (at the expense of a more complex build) it should be possible there, at least?

> Linux lets you use multiple libcs, so (at the expense of a more complex build) it should be possible there, at least?

Linux lets you use no libc if you want, too. I suspect the reason this kind of change doesn't happen is, if you want to make breaking changes like splitting libc, then you might as well fix all the crap APIs, at which point you might as well fix the crap language choice (and use say Rust instead) at which point libc is a low level abstraction that you hardly care about.

I asked this in the Reddit discussion, or something related. I'm thinking it would be interesting to have std::net offer options for swapping in different DNS resolvers, for this specific case, and probably would be interesting if it offered this option for any/all libc functions, especially around network operations.

You make it sound like this is a bug that someone should have fixed, but this is documented and even sensible behavior: doing something different is at best a feature request. The question is whether there is an implementation that they would accept and integrate. If not (and maybe that's the case, as Debian apparently has such a patch and they don't like the concept), I "agree" that they shouof close the issue as "not a bug" or "won't fix" or somethiby.

dnsmasq gets can be used for this. If your sentiment though was that this should be standard, I absolutely agree. The benefit of having a system-wide cache makes it worth it, IMO. `resolverd` or somesuch.

(I've also imagined a similar set up w/ ping, i.e., a pingd, so that local monitoring stuff could ping things without needing to parse ping output or require the ability to open raw sockets.)

I have always found the daemons that come (or don't come) with linux rather odd. I suppose it is a quirk of how it is developed and who is responsible for what?

I agree that ping should probably not use setuid. Setuid seems like a hack to me though I am sure it is a necessary one.

I can't think why ping should need setuid; having the capability for opening a raw socket would be enough, I think. (Unless I misunderstand how capabilities work, but this seems to suffice for Wireshark.)

My Ubuntu Xenial system has /bin/ping as '-rwsr-xr-x' and getcap reports nothing. On the other hand raw(7) says "Only processes with an effective user ID of 0 or the CAP_NET_RAW capability are allowed to open raw sockets" so I would expect setuid to not be needed any more. I assume Canonical has a reason for setting it up this way though I've no idea what that reason is.

UNIX-derived systems tend to have a habit of requiring root for anything that even remotely might want to be restricted: the example that comes to mind is reserving ports 0-1024 for root, thus requiring that most daemons to start as root instead of an unprivileged user.

There's a nice capability that allows non-root binaries to use low ports, too!

While there is a bug filed in glibc against this behavior, after reading the thread in that bug tracker I absolutely agree with the developers there that this is not a bug in glibc... it is at best a feature request.

And lookup in resolv.conf can still fail due to invalid cache of resolv.conf, it just won't happen multiple times in a row.

Previous discussion on /r/rust, with the author in-thread answering questions: https://www.reddit.com/r/rust/comments/6ai0ga/the_story_of_a...

Any clue if musl has the same issue?

It's buried in the bugs but I noticed this when I skimmed them: https://github.com/rust-lang/libc/pull/585#issuecomment-2977...

I'm not sure if that means it means that musl doesn't provide the workaround or if musl doesn't have the bug at all.

Reply on news.ycombinator.com