Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't tug on that, you never know what it might be attached to

blog.plover.com

Post reply on HN
Print view View original

21–30 of 98 posts

Re: Don't tug on that, you never know what it might be attached to

#21

Post by eridius »

JoshTriplett wrote: post #12
wtbob wrote: post #9

What's funny is that in this case the dynamic loader was sanitising something irrelevant to the actual capability granted, which seems to me should be a bug. Also, I'll be an advocate for just starting emacs with systemd, and never worrying about it again.

> What's funny is that in this case the dynamic loader was sanitising something irrelevant to the actual capability granted, which seems to me should be a bug. EDIT: fixed incorrect description of the yak-shaving conclusion. The dynamic loader did so because it ran with an extra capability that the user invoking it didn't already have. Most of that sanitizing exists to prevent the user from gaining those privileges t…

No, it was the dynamic loader that did the sanitizing. Mark said that he thought of Perl's sanitizing, and had ruled it out, and then explicitly said it was the dynamic loader that did the sanitizing in this case.

Re: Don't tug on that, you never know what it might be attached to

#22

Post by ars »

JoshTriplett wrote: post #12
wtbob wrote: post #9

What's funny is that in this case the dynamic loader was sanitising something irrelevant to the actual capability granted, which seems to me should be a bug. Also, I'll be an advocate for just starting emacs with systemd, and never worrying about it again.

> What's funny is that in this case the dynamic loader was sanitising something irrelevant to the actual capability granted, which seems to me should be a bug. EDIT: fixed incorrect description of the yak-shaving conclusion. The dynamic loader did so because it ran with an extra capability that the user invoking it didn't already have. Most of that sanitizing exists to prevent the user from gaining those privileges t…

> I'm somewhat surprised that there isn't a sysctl to disable the reservation of ports 0-1023.

There is: /proc/sys/net/ipv4/ip_local_port_range

Re: Don't tug on that, you never know what it might be attached to

#24

Post by 616c »

krylon wrote: post #8

As a sysadmin on a Windows network of ~100 computers, this story makes me want to cry, although maybe for the wrong reason: I see weird problems of the sort "It did work before I went on my lunch break" on a fairly regular basis. How often would I like to go down the rabbit hole and explore these problems in such depth, but if I did that, I would hardly get any work done. The frequency at which our users run into the…

I am in a similar boat.

With DSC, I am increasingly excited with the idea end user computers can also shift to immutable, or approaching what we call immutable, infrastructure that has logically valid weight in the communities represented here.

The problem? Culture. So many people do not understand when I say the following things:

- Do not install with the GUI, please use the deployment system to document unattended installation.

- You should not have to log into a computer and manually install and customize things, especially if you forget to document.

- You should not be doing things, install, configuration change, with following this AND updating the team in your notes, so when I ask you, you in fact remember.

These things are the product of less fires, as I see it, and why I too have to re-image everything (although is largely out of concern for any malware, especially with the majority of our userbase).

Re: Don't tug on that, you never know what it might be attached to

#25

Post by AznHisoka »

cantrevealname wrote: post #16
userbinator wrote: post #2

Great debugging, and an example of the sort of behaviour that long dependency chains can expose. Or rather, I did until this week, when it suddenly stopped working. When this happens to me, the first thing that I ask myself is "what changed?", and I'm usually able to track down the cause to some configuration change. Incidentally, this is also why I never like modifying a working system unless it's absolutely necessa…

> Incidentally, this is also why I never like modifying a working system unless it's absolutely necessary. It's why I find auto-updating apps so infuriating. The trend is that every app, OS, and driver insists on being self-updating. It's going to be very difficult to maintain a reliable system if you're doing anything complex. Privacy issues aside, that's another reason I never plan to use the continuously self-upda…

I hate apps that do 1 job and do it extremely well and it insists I update just so I am on the latest version. It works now stop bugging me. I don't care if you changed the color scheme!

Re: Don't tug on that, you never know what it might be attached to

#26

Post by jrockway »

JoshTriplett wrote: post #12
wtbob wrote: post #9

What's funny is that in this case the dynamic loader was sanitising something irrelevant to the actual capability granted, which seems to me should be a bug. Also, I'll be an advocate for just starting emacs with systemd, and never worrying about it again.

> What's funny is that in this case the dynamic loader was sanitising something irrelevant to the actual capability granted, which seems to me should be a bug. EDIT: fixed incorrect description of the yak-shaving conclusion. The dynamic loader did so because it ran with an extra capability that the user invoking it didn't already have. Most of that sanitizing exists to prevent the user from gaining those privileges t…

I have to agree. It seems the vast majority of daemons that run as root only do that to get the special port they want. It made a tiny bit of sense in the days of multi-user systems. Those days are over.

Re: Don't tug on that, you never know what it might be attached to

#27

Post by JoshTriplett »

eridius wrote: post #21
JoshTriplett wrote: post #12

Earlier quoted context omitted.

> What's funny is that in this case the dynamic loader was sanitising something irrelevant to the actual capability granted, which seems to me should be a bug. EDIT: fixed incorrect description of the yak-shaving conclusion. The dynamic loader did so because it ran with an extra capability that the user invoking it didn't already have. Most of that sanitizing exists to prevent the user from gaining those privileges t…

No, it was the dynamic loader that did the sanitizing. Mark said that he thought of Perl's sanitizing, and had ruled it out, and then explicitly said it was the dynamic loader that did the sanitizing in this case.

Thanks for the correction; fixed. I misremembered that bit of the yak-shaving adventure when I went to write my comment.

The conclusion still holds, though: I don't think special-casing particular capabilities makes sense. And in the case of the dynamic linker, it doesn't actually have that information available; it relies on the AT_SECURE bit set in the process's "auxiliary vector" (see "man getauxval"), which the kernel sets when the process has any privilege its caller didn't have.

Re: Don't tug on that, you never know what it might be attached to

#28

Post by JoshTriplett »

ars wrote: post #22
JoshTriplett wrote: post #12

Earlier quoted context omitted.

> What's funny is that in this case the dynamic loader was sanitising something irrelevant to the actual capability granted, which seems to me should be a bug. EDIT: fixed incorrect description of the yak-shaving conclusion. The dynamic loader did so because it ran with an extra capability that the user invoking it didn't already have. Most of that sanitizing exists to prevent the user from gaining those privileges t…

> I'm somewhat surprised that there isn't a sysctl to disable the reservation of ports 0-1023. There is: /proc/sys/net/ipv4/ip_local_port_range

That does something entirely different; see Documentation/networking/ip-sysctl.txt (online version at https://www.kernel.org/doc/Documentation/networking/ip-sysct...). ip_local_port_range sets the range of ports used as source ports for outbound connections that don't bind to a specific port.

I checked for a sysctl controlling the ability to bind to privileged ports before writing my comment. The relevant code in the kernel compares against a hardcoded #define PROT_SOCK 1024, and doesn't have any means to disable that check. See inet_bind in net/ipv4/af_inet.c .

Re: Don't tug on that, you never know what it might be attached to

#29

Post by groby_b »

cantrevealname wrote: post #16
userbinator wrote: post #2

Great debugging, and an example of the sort of behaviour that long dependency chains can expose. Or rather, I did until this week, when it suddenly stopped working. When this happens to me, the first thing that I ask myself is "what changed?", and I'm usually able to track down the cause to some configuration change. Incidentally, this is also why I never like modifying a working system unless it's absolutely necessa…

> Incidentally, this is also why I never like modifying a working system unless it's absolutely necessary. It's why I find auto-updating apps so infuriating. The trend is that every app, OS, and driver insists on being self-updating. It's going to be very difficult to maintain a reliable system if you're doing anything complex. Privacy issues aside, that's another reason I never plan to use the continuously self-upda…

On the other hand, chasing after CVEs is also infuriating, but in the opposite direction. auto-update makes it possible to live in an environment where security issues are found by the bucket load every day.

There really isn't a good answer either way, but between "breaks occasionally" and "needs a full-time admin, but updates are vetted", I prefer option 1 for my private systems, and option 2 for things that run in production.

Re: Don't tug on that, you never know what it might be attached to

#30

Post by vacri »

krylon wrote: post #8

As a sysadmin on a Windows network of ~100 computers, this story makes me want to cry, although maybe for the wrong reason: I see weird problems of the sort "It did work before I went on my lunch break" on a fairly regular basis. How often would I like to go down the rabbit hole and explore these problems in such depth, but if I did that, I would hardly get any work done. The frequency at which our users run into the…

One of the biggest cultural changes I had when I jumped the fence from Windows to Linux was the reboot. On Windows, the culture was strongly "reboot first, if it still happens, then it's a problem". On linux, it was a measure of last resort, because then you can't fix the problem (as you say).

Obviously the latter is the best way, but it's interesting that the culture of the two systems is so different, no doubt borne from Windows' legacy era.

Post reply on HN