Invalid APE request forming #934
Labels
No labels
P0
P1
P2
P3
badger
frostfs-adm
frostfs-cli
frostfs-ir
frostfs-lens
frostfs-node
good first issue
triage
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/frostfs-node#934
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
APE chain rules that was set as local overrides work incorrectly
Expected Behavior
Access denies on operations that is specified in chain rules.
Current Behavior
Rules not found so we can create container/put object
Possible Solution
As I can see when we check APE rules in node we not always use appropriate namespace:
""
namespace toroot
but when form namespace from request don't do the same and try to find rules in""
ns though they are inroot
. Actually, for object service (at least forSend
) we don't take into account namespace at all.ns
suffixSteps to Reproduce (for bugs)
The following test should pass (note for the two last tests we need registered
kapusta.nns
(nns becausens
currently cannot be TLD) inNNS
):Regression
No
Your Environment
d13e37f70b
I suppose you are right about setting the empty namespace in Container Service - that approach should be fixed.
But let's consider this test:
You cannot expect an error because you have just created a rule about restricting actions for a container (with operation related to object manipulating, not container)
I would expect error because I have just created a rule with native.ResourceFormatRootContainerObjects resource (
"native:object//%s/*"
)@aarifullin @fyrchik
Could you clarify a little this (using chain rules from root namespace when handle
ListContainers
request)?I wonder If this final behavior or we can expect that namespace will be determined from
frostfsid
contract (using address of request owner)?Among other things, can I be able to restrict this listing by owner from request?
cc @alexvanin
Please, check this out: #940
This idea is implemented in this PR :)
Despite I have created the pull-request, some parts of the issue still cannot be reproduced and I suggest to consider them and discuss
check restrict put object
is OK. You have successfully created the policy and cannot put a new objectcheck restrict put object with name
is not OK (FMPOV). You are trying to create a container and expect an error. Why? The previous policy does not relate to container managment. But, further, expecting for object put operation deny is OKcheck restrict create container in custom ns
: you need to not forget to add namespace kapusta to frostfs-id contract for this ownerAlso you need to register
ns, kapusta.ns
in NNS contract to create container with such domain params. The rule workscheck restrict create container in root ns and can create in another ns
: You need to expect an error forbecause you left previous rule for the namespace kapusta
As soon as the PR will be merged, container service will scan a namespace for ownerID from frostfs-id contract (Put, List method). Otherwise, a namespace is read from container's Zone property for those methods that suppose a container does exist (Get, SetExtendedACL etc.)
The first and the second cases both has typo
should be
(I'll update description)
I suppose we should forbid container creation if its owner from
namespace1
but trying to create container ins zonenamespace2.ns
. Otherwise he can bypass (current behavior with PR) restriction rule that forbids creation any container in nsnamespace2
(case 4 above)Whoops, fixed test code in issue
Is there any RP that resolve problem with namespace in object service ?
Closed via #940
cc @aarifullin
@dkirillov It seems this one #903
It does for
But I really forgot to introduce it for other methods (by requestContext)
I'll make PR
Can we reopen this task then?
#952
@aarifullin @fyrchik
Sorry, but here (and for LIst the same)
we have to write
hex.EncodeToString(pk.Bytes())
instead ofpk.String()