Add "Rule Group" and its corresponding subkeys

[love-code-yeyixiao]

Rule groups can be convenient for managing rules, and their subkeys can be useful in the following scenario: in an office public system that is subject permission control, multiple users have to share the same account. And users want to use MajorPrivacy to ensure that their documents are not viewed by each other. In this, a single UserKey is not very useful. If different keys are set for different rules, perhaps this problem can be solved. However, the UserKey should provide restrictive option that does not allow the creation of discrete rules.

[DavidXanatos]

to be honest this should be done on the FS leven with DACLs in an office scenario the IT department would be the holder of the "user" key

[love-code-yeyixiao]

That is an ideal situation.But the actual circustmance is,every remote desktop user requires administrative privllages to install some bad-designed softwares that need to be run in an elevated token. And at the same time,we have no longer a user group named "PowerUser",as a result each user can modify the owner of any files in order to access unapproved files.But I believe MP can solve the problem with the solutions above. ---Original--- From: ***@***.***> Date: Sun, Aug 3, 2025 16:32 PM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [xanasoft/MajorPrivacy] Add "Rule Group" and its correspondingsubkeys (Issue #44) DavidXanatos left a comment (xanasoft/MajorPrivacy#44) to be honest this should be done on the FS leven with DACLs in an office scenario the IT department would be the holder of the "user" key — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[DavidXanatos]

I don't see how, you are requesting multiple user keys, so how would we arbitrate when user1 key says only user1 access to file x and users2 hey says only user2 access to file x.
I think the proper solution would be to add user SIDs as an additional parameter to the rules and stick to one "user" key held by the IT guys

[love-code-yeyixiao]

The way to determine final access rights is simple: use preemption. The user who first declares unique access to a file will be granted their permission, and any subsequent attempts to bring the file under control will be overridden unless modified using the Master Key.

…

---Original--- From: ***@***.***> Date: Sun, Aug 3, 2025 16:32 PM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [xanasoft/MajorPrivacy] Add "Rule Group" and its correspondingsubkeys (Issue #44) DavidXanatos left a comment (xanasoft/MajorPrivacy#44) to be honest this should be done on the FS leven with DACLs in an office scenario the IT department would be the holder of the "user" key — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[DavidXanatos]

Its not simple as we don't have an above user authority which could determine preemption, any user can timestamp their rule with an earlier timestamp then already existing rules.
We would need to invoke a trusted 3rd party timestamp provider.
And even then as soon as a user changes a rule he looses the old timestamp and will look like a rule create right now, this could be mediated by only time stamping a hash of a part of the rules config but still its not a self-reliant approach.

[love-code-yeyixiao]

Then we just check if users have the real permissions to related files when they try creating or modifiying a rule's scope  without a masterkey. If they actually have no the access to those files(in the aspect of rules),then refuse the rules to be applied.

…

---Original--- From: ***@***.***> Date: Sun, Aug 3, 2025 18:20 PM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [xanasoft/MajorPrivacy] Add "Rule Group" and its correspondingsubkeys (Issue #44) DavidXanatos left a comment (xanasoft/MajorPrivacy#44) Its not simple as we don't have an above user authority which could determine preemption, any user can timestamp their rule with an earlier timestamp then already existing rules. We would need to invoke a trusted 3rd party timestamp provider. And even then as soon as a user changes a rule he looses the old timestamp and will look like a rule create right now, this could be mediated by only time stamping a hash of a part of the rules config but still its not a self-reliant approach. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[DavidXanatos]

well but then we run again into "... each user can modify the owner of any files in order to access unapproved files." as you wrote above

[love-code-yeyixiao]

So we don't depend on DACL,we just check if the user have enough permissions to the files according to MP rules. YeYixiao ***@***.***

…

---Original--- From: ***@***.***> Date: Mon, Aug 4, 2025 14:40 PM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [xanasoft/MajorPrivacy] Add "Rule Group" and its correspondingsubkeys (Issue #44) DavidXanatos left a comment (xanasoft/MajorPrivacy#44) well but then we run again into "... each user can modify the owner of any files in order to access unapproved files." as you wrote above — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>