Feature Request
Is your feature request related to a problem? Please describe:
In KCL's introduction there are a few notes about security:
Safety and maintainability: KCL's domain-oriented nature avoids system-level functions, minimizing noise, security risks, and maintenance overhead.
General-purpose languages can often be over-engineered, going beyond the requirements of the problem being solved. These languages can also present various security issues, such as problems with the ability boundary, such as accessing I/O, network, code infinite looping, and other security risks.
However, the current file package does not abide by these rules, in my opinion. For example, in a filesystem that looks like this:
.
└── Users
└── macropower
├── secret.txt
└── my-kcl-pkg
├── kcl.mod
└── main.k
KCL code in main.k can easily read, write to, delete, etc., my secret.txt file.
Describe the feature you'd like:
I think that, at least by default, file should not allow any operations outside of the current module. (Or, in the very least, the root module.)
Kustomize has --load-restrictor which implements this feature, for example. By default, it uses LoadRestrictionsRootOnly, which prevents resolving outside the root kustomization, but you can pass LoadRestrictionsNone to disable these restrictions if needed.
Describe alternatives you've considered:
Teachability, Documentation, Adoption, Migration Strategy:
Unsure of how common it is to do this intentionally, but unfortunately I think this would likely be breaking for some use cases (i.e. people would need to change their settings or start using a new flag).
Feature Request
Is your feature request related to a problem? Please describe:
In KCL's introduction there are a few notes about security:
However, the current
filepackage does not abide by these rules, in my opinion. For example, in a filesystem that looks like this:KCL code in main.k can easily read, write to, delete, etc., my secret.txt file.
Describe the feature you'd like:
I think that, at least by default,
fileshould not allow any operations outside of the current module. (Or, in the very least, the root module.)Kustomize has
--load-restrictorwhich implements this feature, for example. By default, it usesLoadRestrictionsRootOnly, which prevents resolving outside the root kustomization, but you can passLoadRestrictionsNoneto disable these restrictions if needed.Describe alternatives you've considered:
Teachability, Documentation, Adoption, Migration Strategy:
Unsure of how common it is to do this intentionally, but unfortunately I think this would likely be breaking for some use cases (i.e. people would need to change their settings or start using a new flag).