Dstat project ended due to RedHat replacing it with its own dstat tool • Hacker News Board

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#151

Post by lstamour » Fri, May 24, 2019, 2:24 AM UTC

mehrdadn wrote: post #75

lstamour wrote: post #62

Earlier quoted context omitted.

I can see how the original CVE patch removed using the current working directory for loading plugins, but it seems like less of a security issue to simply look up one directory relative to the current binary install, assuming the binary is stored in ./bin after being built and plugins would be stored in ./shared ... Now, it might be inconsiderate to look up a folder when one could be preconfigured based on a common r…

This isn't relative to the binary install, it's relative to argv[0]. It's the same security issue -- that argument is under user control. You can make a symlink to your target wherever you want and then argv[0] will be the symlink location. I don't think there is any secure way to get the current script path in Python.

Would something based on __file__ be more preferred, then?

If so, it could be argued the bug already existed and this patch simply uses the existing behaviour...

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#152

Post by mehrdadn » Fri, May 24, 2019, 2:39 AM UTC

lstamour wrote: post #151

mehrdadn wrote: post #75

Earlier quoted context omitted.

This isn't relative to the binary install, it's relative to argv[0]. It's the same security issue -- that argument is under user control. You can make a symlink to your target wherever you want and then argv[0] will be the symlink location. I don't think there is any secure way to get the current script path in Python.

Would something based on __file__ be more preferred, then? If so, it could be argued the bug already existed and this patch simply uses the existing behaviour...

I don't think __file__ would be any different... it's not even an absolute path necessarily. That's why I said I don't think there's any secure way to do this in Python.

You're right though, I didn't see the issue was still there. The home directory should also not be there either. I think I looked at this too hastily but now I'm confused too.

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#153

Post by mehrdadn » Fri, May 24, 2019, 2:42 AM UTC

contras1970 wrote: post #109

mehrdadn wrote: post #75

Earlier quoted context omitted.

This isn't relative to the binary install, it's relative to argv[0]. It's the same security issue -- that argument is under user control. You can make a symlink to your target wherever you want and then argv[0] will be the symlink location. I don't think there is any secure way to get the current script path in Python.

so you install dstat in /usr/bin/dstat + /usr/share/dstat (because you are root), and an attacker creates /home/eve/bin/dstat with /home/eve/share/dstat/evil.py. why would you run /home/eve/bin/dstat? if eve can get you to run dstat from here ~/bin, why wouldn't she just have ~/bin/dstat with completely different contents? i'm still convinced this is cargocult security.

Edit/Update: You're right; I'm wrong -- I don't think this is the concern. Namely, I completely missed that the bug was already there in another line, and that the home directory was also being scanned. So it can't be a privilege escalation issue. Moreover I forgot that setuid doesn't work for scripts, so that shouldn't be the issue either. Not sure what's going on now either; I'm confused too.

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#154

Post by dagwieers » Fri, May 24, 2019, 9:23 AM UTC

pas wrote: post #127

gigatexal wrote: post #57

Why not come up with a new name for the project instead of rage quitting?

It was already dead, so pragmatically there was nothing to do, this is just a swan dance on RH's bugzilla. Yes, RH should and could have filed and issue saying that they started working on a fork/port-to-PCP, and they intend to provide the dstat executable. But usually at that point, the work is already started, and there's almost nothing to be done. How long RH should wait for that ticket? What if the maintainer say…

It wasn't abandoned, it didn't see any maintenance for 18 months.

I don't get paid for doing this work. Red Hat does. They get paid for offering it to customers that apparently demands that it ships with RHEL8. They have been shipping it with RHEL since RHEL3.

They haven't contributed to it ever in that timespan.

They could have paid me for maintaining it, they could have offered to maintain it for me. (Because it is a lot of work to accept and verify pull requests). I am a freelancer, I have to work for a living I don't have a lot of free time.

Instead, they ripped out the plugin backend, added the PCP backend and now you can't use it as a drop-in tool that can't run PCP. Your synology NAS, WRT router or JeOS platform. Because Red Hat does not care about anything other than RHEL. They are business-oriented. And that's fine.

Is the Open Source ecosystem better off ? I sincerely doubt it. It's being replaced by paid-for engineers with business interests. In the long term it is killing the community.

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#155

Post by kamane » Fri, May 24, 2019, 2:10 PM UTC

dagwieers wrote: post #154

pas wrote: post #127

Earlier quoted context omitted.

It was already dead, so pragmatically there was nothing to do, this is just a swan dance on RH's bugzilla. Yes, RH should and could have filed and issue saying that they started working on a fork/port-to-PCP, and they intend to provide the dstat executable. But usually at that point, the work is already started, and there's almost nothing to be done. How long RH should wait for that ticket? What if the maintainer say…

It wasn't abandoned, it didn't see any maintenance for 18 months. I don't get paid for doing this work. Red Hat does. They get paid for offering it to customers that apparently demands that it ships with RHEL8. They have been shipping it with RHEL since RHEL3. They haven't contributed to it ever in that timespan. They could have paid me for maintaining it, they could have offered to maintain it for me. (Because it is…

Thanks Dag alot for the dstat tool, I am using it till this day. As for opensource and community I think it would be reasonable to still have it under different name if you'll consider it after some time and still develop some functionality or curate and merge pull requests.

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#156

Post by user5994461 » Sun, May 26, 2019, 12:36 PM UTC

mehrdadn wrote: post #152

lstamour wrote: post #151

Earlier quoted context omitted.

Would something based on __file__ be more preferred, then? If so, it could be argued the bug already existed and this patch simply uses the existing behaviour...

I don't think __file__ would be any different... it's not even an absolute path necessarily. That's why I said I don't think there's any secure way to do this in Python. You're right though, I didn't see the issue was still there. The home directory should also not be there either. I think I looked at this too hastily but now I'm confused too.

    os.path.realpath(__file__)

That will give you the absolute path of the current python script, dereferencing any symlink and the .. notation.

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#157

Post by mehrdadn » Sun, May 26, 2019, 12:41 PM UTC

user5994461 wrote: post #156

mehrdadn wrote: post #152

Earlier quoted context omitted.

I don't think __file__ would be any different... it's not even an absolute path necessarily. That's why I said I don't think there's any secure way to do this in Python. You're right though, I didn't see the issue was still there. The home directory should also not be there either. I think I looked at this too hastily but now I'm confused too.

os.path.realpath(__file__) That will give you the absolute path of the current python script, dereferencing any symlink and the .. notation.

It will also be insecure due to a race condition.

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#158

Post by user5994461 » Sun, May 26, 2019, 12:56 PM UTC

mehrdadn wrote: post #150

Macha wrote: post #112

Earlier quoted context omitted.

Arch doesn't promise support. Red Hat does. If software in Arch is unsupported in the near future but currently works, that's less of a problem than software in RHEL becoming definitely unsupported during the release lifetime.

Yes but that doesn't really answer my question. My question was if these programs use Python 3 then why would Arch -- which generally has the latest versions of programs unmodified -- have them depending on Python 2. You just explained why depending on Python 2 is not a problem... which is answering a different question.

Anything python2 is a problem, because Python 2 is officially end of life in January 2020. It is being dropped from all major linux distributions, along any software that depends on it.

RedHat 8 that just got released this month doesn't have it. Not sure when is the next release/update cycle for Arch, that will drop it. Keeping in mind that Arch probably doesn't care about doing things last minute or even after the due date.

Re: Dstat project ended due to RedHat replacing it with its own dstat tool

#159

Post by user5994461 » Sun, May 26, 2019, 1:25 PM UTC

cpitman wrote: post #40

peterwwillis wrote: post #35

Honest question: aside from "they provide Enterprise support", does anyone have a reason they would actually use redhat or centos for new servers? Why not use a Debian-derived one, which seems to both be more common, and have less constant creepy corporate influences?

Disclaimer, I work for Red Hat. That being said... The big things for our customers isn't just support, it is stability. When you build your systems on RHEL 8 (just released), you will get 10+ years of support and patches for that system. Those changes are all guarenteed to be binary compatible, so the risk of patching ever impacting systems is low. If there is a critical security vulnerability (say Heartbleed in ope…

I'd say both stability and update.

Debian never upgrades anything (unless security issue). All packages are frozen at the time of the initial major release. Have fun using curl/htop/nginx/libreoffice from 5-10 years ago, plenty of obscure bugs and missing command line flags.

RHEL actually maintain their system packages.