3 ms·

Yeah, no. You can't expose generalized query functionality without either encoding the security constraints in the datastore query layer (which is really, real

Yeah, no. You can't expose generalized query functionality without either encoding the security constraints in the datastore query layer (which is really, really hard, we are talking column-level security constraints and worse) or limiting the expressiveness of your query layer. That's the trade off and, in most real world systems, the data stores are wide open to the developer because expressivity wins. Yes, the technology is there to secure databases at the row level, for example, but people don't use it. They just use a user/pass with total access. A lot of folks are tossing HTTP endpoints on data stores without thinking through the security/expressiveness tradeoff.

dragonwriter 10y ago
> You can't expose generalized query functionality without either encoding the security constraints in the datastore query layer (which is really, really hard, we are talking column-level security constraints and worse) or limiting the expressiveness of your query layer. Column and even row-level security constraints are not "really, really hard" to use in modern DBs, and you have to do the analysis of what people should be able to access and effect on that level to build the app, no matter whether you are implementing the constraints through a separate application layer or through the DB itself.
- carsongross 10y ago
  A user can only see the salaries of all his direct reports. Again, there's a reason why almost every web app built in the last twenty years just used user/pass credentials and didn't implement db security beyond that: expressiveness. But I'm not gonna change your mind on it today. Just think about it for a while.
  - dragonwriter 10y ago
    > A user can only see the salaries of all his direct reports. With an employee-salary table, that's a fairly simple row-level security rule. > Again, there's a reason why almost every web app built in the last twenty years just used user/pass credentials and didn't implement db security beyond that: expressiveness. I agree that there is a reason, but that's not it; there is a combination of the lack of features in popular (particularly free) databases in the early part of the period (heck, MySQL/MariaDB still doesn't support row-level security), inertia, and lack of database knowledge among web app developers. > But I'm not gonna change your mind on it today. Just think about it for a while. This is not a new issue for me; I have been thinking about it for quite a long while.

dragonwriter 10y ago

> You can't expose generalized query functionality without either encoding the security constraints in the datastore query layer (which is really, really hard, we are talking column-level security constraints and worse) or limiting the expressiveness of your query layer. Column and even row-level security constraints are not "really, really hard" to use in modern DBs, and you have to do the analysis of what people should be able to access and effect on that level to build the app, no matter whether you are implementing the constraints through a separate application layer or through the DB itself.

carsongross 10y ago
A user can only see the salaries of all his direct reports. Again, there's a reason why almost every web app built in the last twenty years just used user/pass credentials and didn't implement db security beyond that: expressiveness. But I'm not gonna change your mind on it today. Just think about it for a while.
- dragonwriter 10y ago
  > A user can only see the salaries of all his direct reports. With an employee-salary table, that's a fairly simple row-level security rule. > Again, there's a reason why almost every web app built in the last twenty years just used user/pass credentials and didn't implement db security beyond that: expressiveness. I agree that there is a reason, but that's not it; there is a combination of the lack of features in popular (particularly free) databases in the early part of the period (heck, MySQL/MariaDB still doesn't support row-level security), inertia, and lack of database knowledge among web app developers. > But I'm not gonna change your mind on it today. Just think about it for a while. This is not a new issue for me; I have been thinking about it for quite a long while.