rob05c commented on issue #4043: TO: Internal Server error is returned when
user not tenant of the ds assigns/deletes required capability
URL: https://github.com/apache/trafficcontrol/issues/4043#issuecomment-547670913
Removing unprivileged DSes in `/deliveryservices` endpoints isn't just for
security, it's a convenience and improves usability. There's no need for a user
to see DSes they don't own, so it saves them an extra request (or checking some
field on the DS) to figure out whether they have access to it.
>Just because a DS with id 1 and a DS with id 3 both exist is no guarantee
that a DS with id 2 (still) exists
True; but there will always be ways to discover existence. Most data has
name endpoints as well (and IMO we should be moving that direction, away from
IDs). And again, names are always discoverable.
>An error message for creating DSes with duplicate keys can be changed just
as easily.
That would be a huge usability loss. If a user is trying to make a DS, and
doesn't get a message telling them the name is already taken, now they're going
to call our support and ask why it's failing with a cryptic message. And what
is our support to do? Cryptically answer that they must pick another name, but
somehow not let them know that name is taken?
Again, it's a good goal, but obscurity is always a lesser form of security,
and it comes at a cost: when someone really should have access to a DS and the
permissions are a mistake, telling them it doesn't exist is going to create a
lot of confusion. That confusion just doesn't seem worth it, when it isn't
really buying us security anyway.
Suppose someone malicious knows an ID is valid. What can they do, that they
couldn't do anyway? If they have an exploit, they can use it to determine
existence, correlate the name, modify or delete, or whatever else their exploit
allows.
Obscurity _is_ a small security feature; but in this case it's very small
(I'm not sure it exists at all), and comes with a high usability cost.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
