During startup and runtime creation, T#Validate() asserts own constraints after calling ObjectImpl\#Validate(). The latter calls individual attribute validators. In contrast, runtime modification consults only the individual attribute validators in question. Hence, one can cheat on T#Validate() constraints via runtime modification.
Will fail: Error: Validation failed for object 'ws-aklimov7777777.local!lolcat' of type 'Notification': Validation failed: No users/user_groups specified. 👍
Object constraints involving 2+ attributes get an own method which is still called by T#Validate() and additionally during runtime modification. Not sure how the latter can work.
Or each constraint(!) involving 2+ attributes gets an own method which isn't called directly by T#Validate() "anymore", but by individual attribute validators. E.g both the users and user groups attribute check for the constraint bypassed above.
Your Environment
Version used (icinga2 --version): 01d3a1d38
Operating System and version: macOS 14.7
Enabled features (icinga2 feature list): api checker mainlog notification
Describe the bug
During startup and runtime creation, T#Validate() asserts own constraints after calling ObjectImpl\#Validate(). The latter calls individual attribute validators. In contrast, runtime modification consults only the individual attribute validators in question. Hence, one can cheat on T#Validate() constraints via runtime modification.
To Reproduce
prefix/sbin/icinga2 api setupperl -pi -e 's/password = ".*?"/password = "123456"/' prefix/etc/icinga2/conf.d/api-users.confprefix/sbin/icinga2 daemon -dcurl -kvu root:123456 -X PUT -H 'Accept: application/json' -d '{"pretty":true, "attrs":{"command":"mail-host-notification"}}' 'https://127.0.0.1:5665/v1/objects/notifications/ws-aklimov7777777.local!lolcat'Error: Validation failed for object 'ws-aklimov7777777.local!lolcat' of type 'Notification': Validation failed: No users/user_groups specified.👍curl -kvu root:123456 -X PUT -H 'Accept: application/json' -d '{"pretty":true, "attrs":{"command":"mail-host-notification", "users":["icingaadmin"]}}' 'https://127.0.0.1:5665/v1/objects/notifications/ws-aklimov7777777.local!lolcat'👍curl -kvu root:123456 -X POST -H 'Accept: application/json' -d '{"pretty":true, "attrs":{"users":[]}}' 'https://127.0.0.1:5665/v1/objects/notifications/ws-aklimov7777777.local!lolcat'Expected behavior
Object constraints involving 2+ attributes get an own method which is still called by T#Validate() and additionally during runtime modification. Not sure how the latter can work.
Or each constraint(!) involving 2+ attributes gets an own method which isn't called directly by T#Validate() "anymore", but by individual attribute validators. E.g both the users and user groups attribute check for the constraint bypassed above.
Your Environment
icinga2 --version): 01d3a1d38icinga2 feature list): api checker mainlog notificationicinga2 daemon -C): ✅Additional context