8 ms·

CVE-2019-9193: Not a Security Vulnerability

165 points by proboscis 7y ago

kijin 7y ago
While the behavior described might be by design, I'm skeptical of any database query that involves accessing user-specified local files or executing system commands. (MySQL also has the infamous LOAD DATA INFILE query.) They look like band-aids designed for people who can't be bothered to import/export their data using standard shell commands, scripts, pipes, and database-specific dump/restore tools. These kinds of features should be disabled by default.
- TheRealPomax 7y ago
  Sure, but that's a different discussion. No matter how potentially dangerous some software behaviour is, if it's both intentional, and well-documented as being dangerous and intentionally so, there is no CVE.
- stingraycharles 7y ago
  As mentioned in the article, this feature is disabled by default for non-superusers. If you’re talking about a more broad “COPY TO/FROM” is evil, then I think this is a far broader discussion, and I encourage you to get a better understanding of some of the use cases.
- jeffdavis 7y ago
  It's not a "query" and can't be executed by normal users. It's a command, and it's closer to other commands that do similar things, like loading a plugin (i.e. a ".so" file).
- aasasd 7y ago
  > They look like band-aids designed for people who can't be bothered Also those schmucks who like data to be loaded way way faster.
  - saltcured 7y ago
    What is way way faster here? Are you only comparing COPY versus individual row INSERT statements? I prefer using COPY ... STDIN/STDOUT. AFAICT, you get the same bulk table access performance. But, the external file access is via the client, separating DB rights and filesystem rights. When appropriate, you can also SSH to the server and invoke psql as a regular user there, manipulating files under that user's control on the server filesystem. The psql command also provides built-in \COPY command to make it easy to combine several such commands into one transaction in a SQL script. It looks a little like the SQL COPY command, but accesses files on the client side and executes equivalent COPY ... STDIN/STDOUT statements on the server. In Python, you can use the copy_expert() method with psycopg2 connections to access the COPY ... STDIN/STDOUT feature for similar bulk ETL. However, Python will become the performance bottleneck if you try to do any real row-level processing rather than just relaying byte buffers to/from the filesystem.
    - aasasd 7y ago
      MySQL's ‘load data infile’ is much faster than anything going through the client, precisely because it avoids layers of processing. (At least it was way faster back when I was using it.) Dunno about this business in Postgre.
    - pgaddict 7y ago
      You're missing the point. COPY TO/FROM PROGRAM is useful e.g. when you already have the data locally on the server (same filesystem, ...). COPY FROM STDIN/STDOUT are useful when the data are on some other system (say, on a different server, etc). Of course, you might write a script that reads the local data and loads it through a regular client, i.e. something like COPY t FROM PROGRAM 'gunzip -c /path/to/compressed/data.gz'; might be rewritten like gunzip -c /path/to/compressed/data.gz | psql db -c 'copy t from stdin'; but well, that requires some access to the server and ability to execute commands on it (although not as a postgres superuser). Ultimately it's a tradeoff - don't trust your users? Don't give them superuser access, don't grant them the role. It's possible to restrict that in other ways (e.g. security-definer functions + extra validations).
Tostino 7y ago
After reading the discussion, that seems like the entirely right call. The security researchers did not seem too concerned with the feedback they got from the community prior to releasing this CVE.
- mutagen 7y ago
  Yeah, I discovered a flaw in SSH the other day, if my account on the remote server Is listed in the sudoers file I can escalate to root priviliges, as soon as I create a snazzy logo I'm going to get myself a CVE. Seriously though, security research is starting to drift into bizarro land, security contacts at companies are inundated with port-scans asking for bug bounties because there's an open port and now people are registering CVEs on expected and documented behavior.
  - Hello71 7y ago
    starting? Raymond Chen has been blogging about bizarre vulnerability reports for almost 13 years now.
    - tipsysquid 7y ago
      I assume you mean this Raymond Chen of Microsoft[0] [0] https://devblogs.microsoft.com/oldnewthing/author/oldnewthing https://devblogs.microsoft.com/oldnewthing/author/oldnewthin...
  - dx87 7y ago
    A couple of years ago someone made a website about the "Grinch" vulnerability, saying it was going to be bigger than shellshock. The "vulnerability" was that members of the "wheel" admin group could use sudo to run commands as root without a password. Needless to say, RedHat replied that it was intended behavior, but not until the researcher got their 15 minutes of fame on a bunch of tech websites. https://access.redhat.com/articles/1298913 https://access.redhat.com/articles/1298913
  - userbinator 7y ago
    security research is starting to drift into bizarro land Remember that these people are essentially trying to earn a living by finding vulnerabilities, so it's no surprise that they'll try to spin anything as one, regardless of any other considerations. I've used the term "security vultures" before in reference to such things. It's unfortunate that a lot of companies misunderstand or obey their requests, and in the process useful features are destroyed and software becomes more user-hostile.
ZeroCool2u 7y ago
TL;DR Don't grant root to strangers, because they might do something rude with your db.
- deleted 7y ago
  [deleted]
StreamBright 7y ago
Is this the same as somebody executes sudo bash and observes that he got root prompt?
kerng 7y ago
Sounds the same as xp_cmdshell scenarios in past. Although worth pointing out Microsoft there did lock down things further to even disable the feature and it has to be turned on explicitly. That's possibly an improvement Postgress can do to avoid easy pivoting. Its what a less defensive security reply would include, because if hackers use it to pivot it might not look good down the road. But from a pure argument standpoint Postgres is correct, it's more of a defense in depth strategy.
- jarfil 7y ago
  If I understand it correctly, the feature is controlled via a user permission which is not granted by default.
  - kerng 7y ago
    If that is correct, then it's really a non issue I'd say.
- michelpp 7y ago
  Quoting Andreas Freund from the mailing list: """ Btw, the xp_cmdshell thing the author references several times? It can be enabled via tsql if you have a privileged account. https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/xp-cmdshell-server-configuration-option?view=sql-server-2017 https://docs.microsoft.com/en-us/sql/database-engine/configu... and it allows to execute shell code (as a specified user) even when not a sysadmin: https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/xp-cmdshell-transact-sql?view=sql-server-2017#xp_cmdshell-proxy-account https://docs.microsoft.com/en-us/sql/relational-databases/sy... """ so no MS didn't really "lock down" the feature.
  - deleted 7y ago
    [deleted]
  - hobs 7y ago
    If you make a proxy account, AS AN ADMIN. I have personally walked dozens of DBAs through making said proxy account as it was non-trivial to accomplish. Please stop repeating this FUD.
lloydde 7y ago
Direct link to “CVE-2019-9193: Not a Security Vulnerability” https://www.postgresql.org/about/news/1935/ https://www.postgresql.org/about/news/1935/ Which is also currently a banner at postgresql.org titled “4th April 2019: CVE-2019-9193: Not a Security Vulnerability”
- ajross 7y ago
  Per the links in the NVC CVE page, the reporter seems to have retracted it too. It was a bad report. To be fair, it's also a bad feature. But bad features working as intended shouldn't be "vulnerabilities".
  - michelpp 7y ago
    COPY TO/FROM PROGRAM is not a bad feature. It is in fact an amazing and wonderful thing that makes ETL with Postgres much more powerful. Almost all language runtimes can spawn subprocesses. What is your rational for declaring it "bad" with no explanation?
    - ajross 7y ago
      Sigh. We literally went through all this with SQL Server's xp_cmdshell feature already. All the same flame wars apply, I don't have the energy to argue it all again. The community consensus was the MS should make this thing disabled by default, and they did. Postgres should too.
      - michelpp 7y ago
        xp_cmdshell can be re-enabled, from SQL, with the same kind of privileged account postgres requires to run COPY...PROGRAM: https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/xp-cmdshell-server-configuration-option?view=sql-server-2017 https://docs.microsoft.com/en-us/sql/database-engine/configu...
        deleted 7y ago
        [deleted]
based2 7y ago
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9193 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9193
jpeter 7y ago
The researcher should watch this video https://www.youtube.com/watch?v=866olNIzbrk https://www.youtube.com/watch?v=866olNIzbrk
- michelpp 7y ago
  Thank you! Didn't know about that silly Python non-CVE, a great example of the same shallow thinking that created this bogus CVE.
michaelhoffman 7y ago
"It rather involved being on the other side of this airtight hatchway: Writing to the application directory" (2012) Raymond Chen on "security vulnerabilities" that depend on already having superuser status. https://devblogs.microsoft.com/oldnewthing/20121207-00/?p=5893 https://devblogs.microsoft.com/oldnewthing/20121207-00/?p=58... Looks like Microsoft messed up the line breaks on switching to a new blog platform.
- ethbro 7y ago
  > Looks like Microsoft messed up the line breaks on switching to a new blog platform. One could argue Microsoft has been messing up line breaks since 1981.
- felixrabe 7y ago
  Re line breaks: That's Microsoft being poetic :)
- gruez 7y ago
  archived version with proper formatting: https://web.archive.org/web/20170411085434/https://blogs.msdn.microsoft.com/oldnewthing/20121207-00/?p=5893 https://web.archive.org/web/20170411085434/https://blogs.msd...
deleted 7y ago
[deleted]
mixologist 7y ago
If this is CVE, what is Docker then? :) Anyone with privileges to run docker image is basically root on your host.
- imtringued 7y ago
  This is why you should never add your user to the docker group. Just use `sudo docker` or put your docker commands in a script that can only be edited by root and execute the script via sudo with NOPASSWD.
  - ahachete 7y ago
    Much better: replace Docker with https://podman.io/ https://podman.io/, which runs with user privileges, no root.
Derek_MK 7y ago
I kinda went back and forth on this. The initial comments here made me think that this was basically the reporter saying "person with su can do su things". Then I looked at the PostgreSQL statement, which said that the report claimed that users with a read-access role could do the su things, and they said that the claim was not true. And then I looked at the actual report, which stated that you have to have the read-access role, and the execute-access role (or su). So, what it seems like is that both parties didn't represent the actual situation well, but the root (ha) issue was that it was reported as "IF YOU HAVE READ ACCESS (and execute access) THEN YOU CAN EXECUTE ARBITRARY CODE!!11!!!"
- Hello71 7y ago
  allegedly, the reporters only edited their article after publication and widespread criticism.
  - Derek_MK 7y ago
    Oh, if that's the case, then the reporters were just wrong about how the software worked. If it only required the read access, then that would be a legitimate vulnerability.
- codedokode 7y ago
  No, this feature is like ssh, but without any encryption and authentication.
  - kelseyfrancis 7y ago
    What? You have to be authenticated as a superuser or other role with a very specific privilege.
- sslayer 7y ago
  So, is there a difference between and actual vulnerability in the code, and a vulnerability due to unintended misconfiguration? That's what this sounds like (or am I wrong?), And if so, plenty of software can be misconfigured in an unsecured state.
johannkokos 7y ago
This is the original blog post by the author who filed the cve. https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/authenticated-arbitrary-command-execution-on-postgresql-9-3/ https://www.trustwave.com/en-us/resources/blogs/spiderlabs-b...
- deleted 7y ago
  [deleted]
codedokode 7y ago
Running a program remotely from a database client is an awful idea. DB client is not a secure remote shell; if you need a shell access, use ssh. Postgres is making a mistake, developers will run postgres as root (because it is the easiest way to solve problem with permissions), they will write apps that connect to postgres server as root and run SQL queries made from user input.
- gmueckl 7y ago
  You can't run Postgres as root without patching it first. It really wants to run as a low privilege user.
deleted 7y ago
[deleted]
bdarnell 7y ago
I think this is an argument for not giving root/superuser all possible permissions by default. It's OK that granting the `pg_execute_server_program` permission gives access to this feature, but it should still be something you have to opt in to, instead of making database superuser equivalent to the host user that the database runs as. For comparison, in CockroachDB (disclosure: I'm a co-founder of Cockroach Labs), we don't have any features that let you execute server programs, but we do have something analogous to `pg_{read,write}_server_files` via the BACKUP, RESTORE, and IMPORT commands. In order to use these commands with a target on the server's filesystem, though, the database `admin` role isn't enough. The server also needs to be started with the `--external-io-dir` flag (and file operations will be limited to that directory). This gives an extra layer of opt-in before filesystem operations are allowed.
- SpicyLemonZest 7y ago
  It's an argument for sure. But there's a significant maintenance cost to every security boundary you impose, especially when it's as counter-intuitive as "root may not do suchandsuch".

165 points by proboscis 7y ago

While the behavior described might be by design, I'm skeptical of any database query that involves accessing user-specified local files or executing system commands. (MySQL also has the infamous LOAD DATA INFILE query.) They look like band-aids designed for people who can't be bothered to import/export their data using standard shell commands, scripts, pipes, and database-specific dump/restore tools. These kinds of features should be disabled by default.

TheRealPomax 7y ago
Sure, but that's a different discussion. No matter how potentially dangerous some software behaviour is, if it's both intentional, and well-documented as being dangerous and intentionally so, there is no CVE.
stingraycharles 7y ago
As mentioned in the article, this feature is disabled by default for non-superusers. If you’re talking about a more broad “COPY TO/FROM” is evil, then I think this is a far broader discussion, and I encourage you to get a better understanding of some of the use cases.
jeffdavis 7y ago
It's not a "query" and can't be executed by normal users. It's a command, and it's closer to other commands that do similar things, like loading a plugin (i.e. a ".so" file).
aasasd 7y ago
> They look like band-aids designed for people who can't be bothered Also those schmucks who like data to be loaded way way faster.
- saltcured 7y ago
  What is way way faster here? Are you only comparing COPY versus individual row INSERT statements? I prefer using COPY ... STDIN/STDOUT. AFAICT, you get the same bulk table access performance. But, the external file access is via the client, separating DB rights and filesystem rights. When appropriate, you can also SSH to the server and invoke psql as a regular user there, manipulating files under that user's control on the server filesystem. The psql command also provides built-in \COPY command to make it easy to combine several such commands into one transaction in a SQL script. It looks a little like the SQL COPY command, but accesses files on the client side and executes equivalent COPY ... STDIN/STDOUT statements on the server. In Python, you can use the copy_expert() method with psycopg2 connections to access the COPY ... STDIN/STDOUT feature for similar bulk ETL. However, Python will become the performance bottleneck if you try to do any real row-level processing rather than just relaying byte buffers to/from the filesystem.
  - aasasd 7y ago
    MySQL's ‘load data infile’ is much faster than anything going through the client, precisely because it avoids layers of processing. (At least it was way faster back when I was using it.) Dunno about this business in Postgre.
  - pgaddict 7y ago
    You're missing the point. COPY TO/FROM PROGRAM is useful e.g. when you already have the data locally on the server (same filesystem, ...). COPY FROM STDIN/STDOUT are useful when the data are on some other system (say, on a different server, etc). Of course, you might write a script that reads the local data and loads it through a regular client, i.e. something like COPY t FROM PROGRAM 'gunzip -c /path/to/compressed/data.gz'; might be rewritten like gunzip -c /path/to/compressed/data.gz | psql db -c 'copy t from stdin'; but well, that requires some access to the server and ability to execute commands on it (although not as a postgres superuser). Ultimately it's a tradeoff - don't trust your users? Don't give them superuser access, don't grant them the role. It's possible to restrict that in other ways (e.g. security-definer functions + extra validations).

Tostino 7y ago

After reading the discussion, that seems like the entirely right call. The security researchers did not seem too concerned with the feedback they got from the community prior to releasing this CVE.

mutagen 7y ago
Yeah, I discovered a flaw in SSH the other day, if my account on the remote server Is listed in the sudoers file I can escalate to root priviliges, as soon as I create a snazzy logo I'm going to get myself a CVE. Seriously though, security research is starting to drift into bizarro land, security contacts at companies are inundated with port-scans asking for bug bounties because there's an open port and now people are registering CVEs on expected and documented behavior.
- Hello71 7y ago
  starting? Raymond Chen has been blogging about bizarre vulnerability reports for almost 13 years now.
  - tipsysquid 7y ago
    I assume you mean this Raymond Chen of Microsoft[0] [0] https://devblogs.microsoft.com/oldnewthing/author/oldnewthing https://devblogs.microsoft.com/oldnewthing/author/oldnewthin...
- dx87 7y ago
  A couple of years ago someone made a website about the "Grinch" vulnerability, saying it was going to be bigger than shellshock. The "vulnerability" was that members of the "wheel" admin group could use sudo to run commands as root without a password. Needless to say, RedHat replied that it was intended behavior, but not until the researcher got their 15 minutes of fame on a bunch of tech websites. https://access.redhat.com/articles/1298913 https://access.redhat.com/articles/1298913
- userbinator 7y ago
  security research is starting to drift into bizarro land Remember that these people are essentially trying to earn a living by finding vulnerabilities, so it's no surprise that they'll try to spin anything as one, regardless of any other considerations. I've used the term "security vultures" before in reference to such things. It's unfortunate that a lot of companies misunderstand or obey their requests, and in the process useful features are destroyed and software becomes more user-hostile.

ZeroCool2u 7y ago

TL;DR Don't grant root to strangers, because they might do something rude with your db.

deleted 7y ago
[deleted]

StreamBright 7y ago

Is this the same as somebody executes sudo bash and observes that he got root prompt?

kerng 7y ago

Sounds the same as xp_cmdshell scenarios in past. Although worth pointing out Microsoft there did lock down things further to even disable the feature and it has to be turned on explicitly. That's possibly an improvement Postgress can do to avoid easy pivoting. Its what a less defensive security reply would include, because if hackers use it to pivot it might not look good down the road. But from a pure argument standpoint Postgres is correct, it's more of a defense in depth strategy.

jarfil 7y ago
If I understand it correctly, the feature is controlled via a user permission which is not granted by default.
- kerng 7y ago
  If that is correct, then it's really a non issue I'd say.
michelpp 7y ago
Quoting Andreas Freund from the mailing list: """ Btw, the xp_cmdshell thing the author references several times? It can be enabled via tsql if you have a privileged account. https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/xp-cmdshell-server-configuration-option?view=sql-server-2017 https://docs.microsoft.com/en-us/sql/database-engine/configu... and it allows to execute shell code (as a specified user) even when not a sysadmin: https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/xp-cmdshell-transact-sql?view=sql-server-2017#xp_cmdshell-proxy-account https://docs.microsoft.com/en-us/sql/relational-databases/sy... """ so no MS didn't really "lock down" the feature.
- deleted 7y ago
  [deleted]
- hobs 7y ago
  If you make a proxy account, AS AN ADMIN. I have personally walked dozens of DBAs through making said proxy account as it was non-trivial to accomplish. Please stop repeating this FUD.

lloydde 7y ago

Direct link to “CVE-2019-9193: Not a Security Vulnerability” https://www.postgresql.org/about/news/1935/ https://www.postgresql.org/about/news/1935/ Which is also currently a banner at postgresql.org titled “4th April 2019: CVE-2019-9193: Not a Security Vulnerability”

ajross 7y ago
Per the links in the NVC CVE page, the reporter seems to have retracted it too. It was a bad report. To be fair, it's also a bad feature. But bad features working as intended shouldn't be "vulnerabilities".
- michelpp 7y ago
  COPY TO/FROM PROGRAM is not a bad feature. It is in fact an amazing and wonderful thing that makes ETL with Postgres much more powerful. Almost all language runtimes can spawn subprocesses. What is your rational for declaring it "bad" with no explanation?
  - ajross 7y ago
    Sigh. We literally went through all this with SQL Server's xp_cmdshell feature already. All the same flame wars apply, I don't have the energy to argue it all again. The community consensus was the MS should make this thing disabled by default, and they did. Postgres should too.
    - michelpp 7y ago
      xp_cmdshell can be re-enabled, from SQL, with the same kind of privileged account postgres requires to run COPY...PROGRAM: https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/xp-cmdshell-server-configuration-option?view=sql-server-2017 https://docs.microsoft.com/en-us/sql/database-engine/configu...
      - deleted 7y ago
        [deleted]

based2 7y ago

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9193 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9193

jpeter 7y ago

The researcher should watch this video https://www.youtube.com/watch?v=866olNIzbrk https://www.youtube.com/watch?v=866olNIzbrk

michelpp 7y ago
Thank you! Didn't know about that silly Python non-CVE, a great example of the same shallow thinking that created this bogus CVE.

michaelhoffman 7y ago

"It rather involved being on the other side of this airtight hatchway: Writing to the application directory" (2012) Raymond Chen on "security vulnerabilities" that depend on already having superuser status. https://devblogs.microsoft.com/oldnewthing/20121207-00/?p=5893 https://devblogs.microsoft.com/oldnewthing/20121207-00/?p=58... Looks like Microsoft messed up the line breaks on switching to a new blog platform.

ethbro 7y ago
> Looks like Microsoft messed up the line breaks on switching to a new blog platform. One could argue Microsoft has been messing up line breaks since 1981.
felixrabe 7y ago
Re line breaks: That's Microsoft being poetic :)
gruez 7y ago
archived version with proper formatting: https://web.archive.org/web/20170411085434/https://blogs.msdn.microsoft.com/oldnewthing/20121207-00/?p=5893 https://web.archive.org/web/20170411085434/https://blogs.msd...

deleted 7y ago

[deleted]

mixologist 7y ago

If this is CVE, what is Docker then? :) Anyone with privileges to run docker image is basically root on your host.

imtringued 7y ago
This is why you should never add your user to the docker group. Just use `sudo docker` or put your docker commands in a script that can only be edited by root and execute the script via sudo with NOPASSWD.
- ahachete 7y ago
  Much better: replace Docker with https://podman.io/ https://podman.io/, which runs with user privileges, no root.

Derek_MK 7y ago

I kinda went back and forth on this. The initial comments here made me think that this was basically the reporter saying "person with su can do su things". Then I looked at the PostgreSQL statement, which said that the report claimed that users with a read-access role could do the su things, and they said that the claim was not true. And then I looked at the actual report, which stated that you have to have the read-access role, and the execute-access role (or su). So, what it seems like is that both parties didn't represent the actual situation well, but the root (ha) issue was that it was reported as "IF YOU HAVE READ ACCESS (and execute access) THEN YOU CAN EXECUTE ARBITRARY CODE!!11!!!"

Hello71 7y ago
allegedly, the reporters only edited their article after publication and widespread criticism.
- Derek_MK 7y ago
  Oh, if that's the case, then the reporters were just wrong about how the software worked. If it only required the read access, then that would be a legitimate vulnerability.
codedokode 7y ago
No, this feature is like ssh, but without any encryption and authentication.
- kelseyfrancis 7y ago
  What? You have to be authenticated as a superuser or other role with a very specific privilege.
sslayer 7y ago
So, is there a difference between and actual vulnerability in the code, and a vulnerability due to unintended misconfiguration? That's what this sounds like (or am I wrong?), And if so, plenty of software can be misconfigured in an unsecured state.

johannkokos 7y ago

This is the original blog post by the author who filed the cve. https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/authenticated-arbitrary-command-execution-on-postgresql-9-3/ https://www.trustwave.com/en-us/resources/blogs/spiderlabs-b...

deleted 7y ago
[deleted]

codedokode 7y ago

Running a program remotely from a database client is an awful idea. DB client is not a secure remote shell; if you need a shell access, use ssh. Postgres is making a mistake, developers will run postgres as root (because it is the easiest way to solve problem with permissions), they will write apps that connect to postgres server as root and run SQL queries made from user input.

gmueckl 7y ago
You can't run Postgres as root without patching it first. It really wants to run as a low privilege user.

deleted 7y ago

[deleted]

bdarnell 7y ago

I think this is an argument for not giving root/superuser all possible permissions by default. It's OK that granting the `pg_execute_server_program` permission gives access to this feature, but it should still be something you have to opt in to, instead of making database superuser equivalent to the host user that the database runs as. For comparison, in CockroachDB (disclosure: I'm a co-founder of Cockroach Labs), we don't have any features that let you execute server programs, but we do have something analogous to `pg_{read,write}_server_files` via the BACKUP, RESTORE, and IMPORT commands. In order to use these commands with a target on the server's filesystem, though, the database `admin` role isn't enough. The server also needs to be started with the `--external-io-dir` flag (and file operations will be limited to that directory). This gives an extra layer of opt-in before filesystem operations are allowed.

SpicyLemonZest 7y ago
It's an argument for sure. But there's a significant maintenance cost to every security boundary you impose, especially when it's as counter-intuitive as "root may not do suchandsuch".