How to stop Owner Group From Changing

[panzerscope]

Hello all,

I have come across an issue where the "Owner Group" regarding my file permissions keeps getting changes to "Apps". I will change it to the group I need it to be, which is the same name as my user. So in this instance the User is "fadmin" and I will set the Owner Group to "fadmin" as well. However after a time, it will be reverted to the "apps" group.

I have also added "apps" as a user and group to my permission structure to see if it would stop this, but no luck. Does anyone have any ideas ? As an FYI the apps pool is not on the storage volume.

A below example of a folder and permission structure where "Apps" has become the Owner Group again is below.

Many thanks,
p

 

[anodos]

This is the default behavior of TrueCharts, IIRC. It by default recursively alters permissions on host paths. It might be configurable, but I'd raise the issue with them since it seems like a significant POLA violation.

 

[LarsR]

For every Truecharts app its possible to set permissions to "auto config". If you uncheck that box during app setup it shouldn't alter permissions.

 

[anodos]

For every Truecharts app its possible to set permissions to "auto config". If you uncheck that box during app setup it shouldn't alter permissions.

It still does not seem like a safe default. I've seen a few situations where this has broken users.

 

[shadofall]

This is the default behavior of TrueCharts, IIRC. It by default recursively alters permissions on host paths. It might be configurable, but I'd raise the issue with them since it seems like a significant POLA violation.

I would argue that Offical IX apps/apps from run launcher docker, running as root with out notifying users would be much more significant POLA violation than TrueCharts default option of setting the owner to match the non-privileged user of 568/568 (or www-data for nextcloud, or what ever security context the apps needs) to allow the apps to access the data it needs access to, since by default truecharts apps will run as the non-privileged user unless the Source container cant not do so. all of which is presented to the user.

 

[anodos]

I would argue that Offical IX apps/apps from run launcher docker, running as root with out notifying users would be much more significant POLA violation than TrueCharts default option of setting the owner to match the non-privileged user of 568/568 (or www-data for nextcloud, or what ever security context the apps needs) to allow the apps to access the data it needs access to, since by default truecharts apps will run as the non-privileged user unless the Source container cant not do so. all of which is presented to the user.

The problem with a sort of blind recursive chown by default is that you lose information about who created files on existing data.

Although this might be okay for a hobbyist, this can be a huge problem for people using it in a professional setting. Though arguably it's also a problem for hobbyists. For instance, I saw a ticket where user lost access to all of his SMB shares on his second pool shortly after setting /mnt/tank2 as a host path in a TrueCharts app. So in addition to losing access to his shares, the user also lost relevant info about who created which files.

I'd argue that a more sensible thing for TrueCharts to do would be:
1) (default) stat the host path and check nlinks. If dir is empty (nlinks == 2), chown non-recursively. It's pretty clearly a dir created specifically for apps. This ensures your host path has correct permissions.
2) (non-default) allow users to do the recursive chown via checkbox.

@truecharts
^^^ This isn't a formal request. Just a suggestion based on seeing some people experience issues.

I haven't looked closely at kuberentes / apps work (not my wheelhouse), but (assuming this is within a shell script) you can also when doing checks / validation try to `cd` into the host path as uid 568. If this fails it strongly indicates that permissions on a parent path will potentially break access to data on the host path.

 

[shadofall]

its k8s functionality to do this. not something TrueCharts just came up with, and it only recursively applies on root mismatch to the fsgroup security context, unless someone changes it to always recursively apply, the argument could be made maybe shouldnt be default on, but then comes the issue of my application cant see my data! double edge blade.

Given the number of users i've seen who don't understand filesystem ACL's the difference between SMB ACL's and how it all correlates and the number of users who don't know its not docker. educating the users seems like the better idea

k8s professional users wouldn't be having an issue, (of course random IT guy that has no k8s experience is a different story) course they also wouldn't be using scale at this point in part due to the lack of ability to use industry standard backup solutions for k8s. but that's another issue.

at least based on my knowledge of k8s

 

[anodos]

its k8s functionality to do this. not something TrueCharts just came up with, and it only recursively applies on root mismatch to the fsgroup security context, unless someone changes it to always recursively apply, the argument could be made maybe shouldnt be default on, but then comes the issue of my application cant see my data! double edge blade.

Given the number of users i've seen who don't understand filesystem ACL's the difference between SMB ACL's and how it all correlates and the number of users who don't know its not docker. educating the users seems like the better idea

k8s professional users wouldn't be having an issue, (of course random IT guy that has no k8s experience is a different story) course they also wouldn't be using scale at this point in part due to the lack of ability to use industry standard backup solutions for k8s. but that's another issue.

at least based on my knowledge of k8s

Okay. I filed an enhancement request to investigate using 568:568 for runAsUser / runAsGroup on iX apps. Will let our SME for kubernetes deal with it (this is far outside my area of responsibility). If you see areas of our product where we deviate from best-practice feel free to file tickets in our jira.

 

[truecharts]

The problem with a sort of blind recursive chown by default is that you lose information about who created files on existing data.

The original problem with not having auto-permissions as default, was that this setting would put this burden on our staff.
But we need to evaluate what hits our users hardest.

Although this might be okay for a hobbyist, this can be a huge problem for people using it in a professional setting. Though arguably it's also a problem for hobbyists. For instance, I saw a ticket where user lost access to all of his SMB shares on his second pool shortly after setting /mnt/tank2 as a host path in a TrueCharts app. So in addition to losing access to his shares, the user also lost relevant info about who created which files.

We like to cordially remind you that SCALE Apps (the OS side of things) is not a professionally useable product at all at the moment. Due to lack of a solid backup implementation and completely FUBAR-ing the option to use industry standard kubernetes backup solutions.

So generally speaking we would advice against using it at all professionally.

For instance, I saw a ticket where user lost access to all of his SMB shares on his second pool shortly after setting /mnt/tank2 as a host path in a TrueCharts app. So in addition to losing access to his shares, the user also lost relevant info about who created which files.

This is indeed an area that needs work, because this behavior is not warranted.
Sadly enough, we have not recieved a featurerequest or bugreport for the issue you refer to.

However: We would like to note that no "hostPath" storage is, by default, included with our Apps.
Users need to manually add any instance of hostPath storage manually. (With the exception of the Docker-Compose App)

We understand that with the current (crappy) state of the Apps edit/install GUI, users are prone to overlooking settings... It's still the users responsibility. As there are many other cases where settings hostPaths willy-nilly might lead to inherent dataloss, depending on Container design.

I'd argue that a more sensible thing for TrueCharts to do would be:
1) (default) stat the host path and check nlinks. If dir is empty (nlinks == 2), chown non-recursively. It's pretty clearly a dir created specifically for apps. This ensures your host path has correct permissions.
2) (non-default) allow users to do the recursive chown via checkbox.

@truecharts
^^^ This isn't a formal request. Just a suggestion based on seeing some people experience issues.

I haven't looked closely at kuberentes / apps work (not my wheelhouse), but (assuming this is within a shell script) you can also when doing checks / validation try to `cd` into the host path as uid 568. If this fails it strongly indicates that permissions on a parent path will potentially break access to data on the host path.

We'll look into it. But it's making decisions between two evils, which need to be carefully weighted.
Most likely the cleanest solution would be to tie this into the kubernetes "fsGroupChangePolicy" and maybe changing the default.

its k8s functionality to do this. not something TrueCharts just came up with, and it only recursively applies on root mismatch to the fsgroup security context, unless someone changes it to always recursively apply, the argument could be made maybe shouldnt be default on, but then comes the issue of my application cant see my data! double edge blade.

The hostPath autopermissions are made and designed by us.
What you refer to is PVC storage, which behaves differently and is not related to the complaints voiced by @anodos

Okay. I filed an enhancement request to investigate using 568:568 for runAsUser / runAsGroup on iX apps. Will let our SME for kubernetes deal with it (this is far outside my area of responsibility). If you see areas of our product where we deviate from best-practice feel free to file tickets in our jira.

The security issues go a lot further and not limited to iX-Systems helm charts either....
Because it's also important to correctly set ReadOnlyFileSystem, enable enforcing non-root users and disabling privilage escalation.. for example...On top of that, when using devices such as GPU's or USB devices,supplementalgroups also need to be (auto)defined.

It's also not possible to use runAsUser/runAsGroup in a lot of cases. Due to a lot of docker developers still not fully understanding that their PUID/PGID system is not compatible with it.

 

[anodos]

The security issues go a lot further and not limited to iX-Systems helm charts either....
Because it's also important to correctly set ReadOnlyFileSystem, enable enforcing non-root users and disabling privilage escalation.. for example...On top of that, when using devices such as GPU's or USB devices,supplementalgroups also need to be (auto)defined.

It's also not possible to use runAsUser/runAsGroup in a lot of cases. Due to a lot of docker developers still not fully understanding that their PUID/PGID system is not compatible with it.

If you have specific actionable feedback, please file jira tickets. I'm not really the best person to point this out to related to apps implementation.

 

[panzerscope]

For every Truecharts app its possible to set permissions to "auto config". If you uncheck that box during app setup it shouldn't alter permissions.

Is it possible to got back into an App settings and retroactively uncheck "auto config" in order to stop the app changing my permissions settings ? I would have a quick look but not at my TrueNas station this second.

Some interesting conversation surrounding this topic!

 

[truecharts]

If you have specific actionable feedback, please file jira tickets. I'm not really the best person to point this out to related to apps implementation.

Understandable, that's why we generally try to focus on our own work instead of also doing, basically, yours.
But as it was brought up, it was only fair to mention it's not as easy as it looks.

 

[panzerscope]

Just popping my head in on this again, is this something that TrueNas team needs to fix as part of the permissions system ? Wondering if I need to submit something in order to have this looked at, or if there is a way for me to correct this ?

Thanks,
P

 

[anodos]

Just popping my head in on this again, is this something that TrueNas team needs to fix as part of the permissions system ? Wondering if I need to submit something in order to have this looked at, or if there is a way for me to correct this ?

Thanks,
P

There is nothing for us to fix if a third-party catalog is automatically changing permissions. You'll probably need to account for this behavior in how you're setting up permissions (use ACL entries that won't be impacted by chmod from the apps).

 

[panzerscope]

There is nothing for us to fix if a third-party catalog is automatically changing permissions.

Understood.

@truecharts

How do users stop the apps from automatically changing the user permissions?

Thanks!

 

[truecharts]

Understood.

@truecharts

How do users stop the apps from automatically changing the user permissions?

Thanks!

Please be sure to reach out to our support staff next time.
However: there is a clearly labled checkbox to disable this behavior like noted earlier ;-)

 

[panzerscope]

I looked back and see it now, I will uncheck "Auto config" in the apps regarding permissions and see if it resolves. Cheers

 

[homer27081990]

The original problem with not having auto-permissions as default, was that this setting would put this burden on our staff.
But we need to evaluate what hits our users hardest.




We like to cordially remind you that SCALE Apps (the OS side of things) is not a professionally useable product at all at the moment. Due to lack of a solid backup implementation and completely FUBAR-ing the option to use industry standard kubernetes backup solutions.

So generally speaking we would advice against using it at all professionally.


This is indeed an area that needs work, because this behavior is not warranted.
Sadly enough, we have not recieved a featurerequest or bugreport for the issue you refer to.

However: We would like to note that no "hostPath" storage is, by default, included with our Apps.
Users need to manually add any instance of hostPath storage manually. (With the exception of the Docker-Compose App)

We understand that with the current (crappy) state of the Apps edit/install GUI, users are prone to overlooking settings... It's still the users responsibility. As there are many other cases where settings hostPaths willy-nilly might lead to inherent dataloss, depending on Container design.




We'll look into it. But it's making decisions between two evils, which need to be carefully weighted.
Most likely the cleanest solution would be to tie this into the kubernetes "fsGroupChangePolicy" and maybe changing the default.



The hostPath autopermissions are made and designed by us.
What you refer to is PVC storage, which behaves differently and is not related to the complaints voiced by @anodos




The security issues go a lot further and not limited to iX-Systems helm charts either....
Because it's also important to correctly set ReadOnlyFileSystem, enable enforcing non-root users and disabling privilage escalation.. for example...On top of that, when using devices such as GPU's or USB devices,supplementalgroups also need to be (auto)defined.

It's also not possible to use runAsUser/runAsGroup in a lot of cases. Due to a lot of docker developers still not fully understanding that their PUID/PGID system is not compatible with it.

No program should change filesystem settings when they have explicitly been set by the user. I don't mean to offend, but... Its just true. This (although by a big stretch of the imagination) seems to go down a road where having the ability to fine-tune what permissions a platform can and cannot tamper with becomes a sellable add-on...

 

[truecharts]

No program should change filesystem settings when they have explicitly been set by the user. I don't mean to offend, but... Its just true. This (although by a big stretch of the imagination) seems to go down a road where having the ability to fine-tune what permissions a platform can and cannot tamper with becomes a sellable add-on...

It's normal for Helm charts to offer this as an option and we're looking into removing this feature as a default.
However: Linux doesn't have a difference between how permissions are set, it simply doesn't exist.

 

[homer27081990]

It's normal for Helm charts to offer this as an option and we're looking into removing this feature as a default.
However: Linux doesn't have a difference between how permissions are set, it simply doesn't exist.

That is why when one develops for *nix, they develop with the culture of the ecosystem in mind. Changing filesystem Ownership and Permissions descriptors "in the dark" is akin to changing the privacy settings in a windows machine, as far as I am concerned. Meaning, with such an operating profile (of the app), many people would think twice before installing it in their system. In the *nix ecosystem, most apps warn you even if they are run in sudo by you, that they get too much power. A way to operate way far from changing mission critical settings with an attitude "I am the only app here, everything runs for me". Even if the option to eventually stop this behavior (but... in no way fine-tune it, "it" the behavior, not how *nix security descriptors work) exists, consider what people would say if the option didn't exist... And that, I think (without any concrete data, just my feeling) is the reason that the option even exists in the first place. Have a good day.