Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow augmented assignments on __setitem__ ? #128

Open
BluBb-mADe opened this issue Sep 12, 2018 · 2 comments
Open

Allow augmented assignments on __setitem__ ? #128

BluBb-mADe opened this issue Sep 12, 2018 · 2 comments

Comments

@BluBb-mADe
Copy link

BluBb-mADe commented Sep 12, 2018

d = {"test": 0}
d["test"]+=1
>>> Augmented assignment of object items and slices is not allowed.

Why is this a security risk and is it possible to safely allow augmented assignments on mapped c++ objects which implement __getitem__ and __setitem__?
Furthermore is it even possible to allow this without writing a custom transformer?

@BluBb-mADe BluBb-mADe changed the title Why are augmented assignments on __setitem__ not allowed? Allow augmented assignments on __setitem__ ? Sep 12, 2018
@icemac
Copy link
Member

icemac commented Sep 13, 2018

Currently augmented assignment of object items is not allowed because it is currently not checked whether the user is has read and write access to the item.

@stephan-hof You implemented these checks in 1f26049. What was the rationale behind disallowing certain types of augmented assignment?

@stephan-hof
Copy link
Member

stephan-hof commented Sep 13, 2018

This restriction is there for a long time. It has been introduced here: db27fa7

I guess the reason is that restriction python has currently not the possibility to check if the 'write back' into object is allowed. For normal assignments restricted python does

foo[a] = c    
becomes
_write_(foo)[a] = c

However this 'write' check cannot be done with augmented assignment, because the write back happens inside the __iadd__ code of the object.

One possibility to still support augmented assignments could be to transform it into:

foo[a] += 1
becomes
_write_(foo)[a] = _getitem_(foo, a) + 1

Which means the __iadd__ of foo is not called.

Apart from this I have currently no idea how a proper secured __iadd__ could look like.
Probably a change in AccessControl is required as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants