Just a quick follow-up to Marc's response...
On 2/22/16 7:43 AM, Marc-André Pelletier wrote:
On 16-02-22 03:26 AM, Ilya Korniyko wrote:
Configuration is created automatically by puppet, isn't it?
In this case, puppet is not involved. Sudo policies are stored in ldap;
they are applied more-or-less instantly after a change rather than
pending a puppet run.
Does it also include automated tests for this scenarios? If not - why?
Thorough automated tests would have eliminated such mistakes.
Patches and phab tasks are always welcome :) We do a lot of monitoring
for tools, but most current tests are of the form "this should work;
does it?" We have fairly few tests of the form "this should not work;
does it?"
Because writing tests (and, subsequently, sifting through false
positives) is fairly labor-intensive, it's always a judgement call when
to stop writing new ones. That said, I agree that we would benefit from
a suite of tests for basic access controls.
Not really in that particular case: The short of what happened is that
a migration inadvertently caused the default sudo policy rules to return
to all projects - including for those where they had been explicitly
removed and replaced with something more restrictive.
The end result, of course, is that people were able to sudo to root that
weren't *intended* to, but they /technically/ did so correctly according
to the configuration in place.
-- Marc
_______________________________________________
Labs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/labs-l
_______________________________________________
Labs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/labs-l
