3 ms·

If absolute share/ access were the problem, the line below wouldn’t hard-code it twice: https://github.com/dagwieers/dstat/pull/50/files https://github.com/dagw

If absolute share/ access were the problem, the line below wouldn’t hard-code it twice: https://github.com/dagwieers/dstat/pull/50/files https://github.com/dagwieers/dstat/pull/50/files The only bug in this PR that I can see is it might assume the system plugins are more important than the local overrides. Generally you’d put this sort of path in the least priority, to allow for /usr/local to override. That said, obviously hard-coding paths is worse than simply having a default, presumably relative to the current binary/file, and allowing end users and packagers to override/configure the defaults to suit their security preferences, with the default being that the entire package is unzipped with expected relative paths to files... or that’s how I would look at it. The only way to greater security would be to ship a Docker container, Snap package, or similar and mount your own filesystem overlays. :) Or, perhaps keeping a trusted list of plugins somewhere.

Kalium 7y ago
My read is that it's more that access control of `../share` in an unknown part of the filesystem is a matter for some concern. Given that the binary can be put basically anywhere, it would seem to be perilously close to CWD.
- contras1970 7y ago
  no, it's just cargocult security. edit after your reply: if you install in /tmp, you'll end up with /tmp/bin/dstat and /tmp/share/dstat. you're concerned that an attacker could smuggle something into /tmp/share/dstat, but /tmp/bin/dstat is of no worry? what exactly is the threat here? > access control of `../share` in an unknown part of the filesystem is a matter for some concern. Given that the binary can be put basically anywhere, it would seem to be perilously close to CWD. another edit since i cannot reply to you: do you have any examples of the "threat model [which] includes that you can't trust every part of the filesystem you're working from"? something concrete, specific. a particular install prefix that would let you create $prefix/bin/dstat but $prefix/share/dstat would be dangerous. aaand, see my reply at https://news.ycombinator.com/item?id=19989237 https://news.ycombinator.com/item?id=19989237
  - Kalium 7y ago
    I don't know. If your threat model includes that you can't trust every part of the filesystem you're working from, being extra paranoid about it isn't the most unreasonable thing in the world. EDIT: A sibling points out the issue in more detail - https://news.ycombinator.com/item?id=19989237 https://news.ycombinator.com/item?id=19989237

Kalium 7y ago

My read is that it's more that access control of `../share` in an unknown part of the filesystem is a matter for some concern. Given that the binary can be put basically anywhere, it would seem to be perilously close to CWD.

contras1970 7y ago
no, it's just cargocult security. edit after your reply: if you install in /tmp, you'll end up with /tmp/bin/dstat and /tmp/share/dstat. you're concerned that an attacker could smuggle something into /tmp/share/dstat, but /tmp/bin/dstat is of no worry? what exactly is the threat here? > access control of `../share` in an unknown part of the filesystem is a matter for some concern. Given that the binary can be put basically anywhere, it would seem to be perilously close to CWD. another edit since i cannot reply to you: do you have any examples of the "threat model [which] includes that you can't trust every part of the filesystem you're working from"? something concrete, specific. a particular install prefix that would let you create $prefix/bin/dstat but $prefix/share/dstat would be dangerous. aaand, see my reply at https://news.ycombinator.com/item?id=19989237 https://news.ycombinator.com/item?id=19989237
- Kalium 7y ago
  I don't know. If your threat model includes that you can't trust every part of the filesystem you're working from, being extra paranoid about it isn't the most unreasonable thing in the world. EDIT: A sibling points out the issue in more detail - https://news.ycombinator.com/item?id=19989237 https://news.ycombinator.com/item?id=19989237