policies: Store.purchase checks open and close time. Inventory.purchase checks inventory count. Product.purchase checks customer’s age.
Question
Product.purchase update action is an empty action with policies.
Even if it does nothing, but I want to check policies always.
With require_atomic? false in action, always check policies.
Without it, never check policies. Is this intended behavior?
Using require_atomic? false to force policy check is weird,
and I found access_type :strict forces policy check.
Empty action with access_type :filter skips policy check.
Is this intended behavior?
+ small questions (not related to content)
How can I auto generate postgres schema migration? Should I write it manually?
1 & 2: atomic actions don’t bypass policies. Could you describe the specific behavior that you’re seeing? What specifically makes you say that it’s not checking policies?
When you say auto generate postgres schema migration, what do you mean? You can generate migrations for resources with mix ash.codegen name_for_your_changes. Are you referring to something else there?
defmodule SonetLib.TestRepo.Migrations.AddSchema do
@moduledoc """
Updates resources based on their most recent snapshots.
This file was autogenerated with `mix ash_postgres.generate_migrations`
"""
use Ecto.Migration
def up do
create table(:customer, primary_key: false, prefix: "seven_eleven") do
add :id, :uuid, null: false, default: fragment("uuid_generate_v7()"), primary_key: true
add :age, :bigint, null: false
end
end
def down do
drop table(:customer, prefix: "seven_eleven")
end
end
If I generate migration using mix ash.codegen,
I can see prefix: "seven_eleven" in the generated code,
but there is no execute("CREATE SCHEMA seven_eleven").
Okay, I’ve identified the issue. It’s a very specific edge case. Its “skipping” the policy check in the case that an atomic action would induce no changes, however it’s important to note that it only does that when it is explicitly requested that no fields be updated (regardless of their initial value). So a very rare case (to call an update action that statically will not update any fields).
Aside from it being rare, I would not classify this as a security vulnerability because you can already see the record (thats how you’d be updating it in this way), and if an update were to actually happen, it would have been prevented.
Still, its confusing and problematic behavior, especially because it “presents” as if policies are being skipped, which is not a good thing.
Ah, right. Yeah in this case you’ll want to alter the migrations by hand to generate the schema. We could add something into ensure they exist if we haven’t already, would be worth opening an issue in ash_postgres.
This is from the changelog: “when an atomic update is fully skipped, run the query if it could produce errors”. You should see the difference by looking at what SQL queries are run in your reproduction.
It’s not that rare to have an action that can never update your own fields, but it’s rare to have one that can statically update none of its own fields and has side effects and is performed atomically. Actions called after the main resource action are authorized by their respective resource’s policies though, so any “nested” updates would be caught in a future check. Additionally most side effects like that prevent an action from being atomic without explicit action. I.e if you had added a before or after action hook, it would have required that you set require_atomic? false
Actually, this is a security issue. My initial evaluation was wrong. Because you could have hooks running resource actions with authorize?: false, and have been relying on the update policies to prevent those side effects. I will issue a CVE for affected AshPostgres versions when I am back at my computer in a few hours, and I will also see if there is a way to programmatically identify actions that may have been affected.
Okay, this is a separate issue that I will address in the morning as well (luckily not another security related one). In that particular place the schema is not being added to the query.
I was unable to reproduce this. I’m using your repository against the latest ash and ash_postgres. Can you confirm that this occurs in the repo that you provided? Did you have to change it in some way to see that behavior?
