Empty update action with policies?

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?

3. 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").

You can easily reproduce it by running my test in above repository.

Here’s what I seeing.

1. I call Store.purchase action.
2. Store.purchase calls Inventory.purchase thru manage_relationship.
3. Inventory.purchase calls Product.purchase thru manage_relationship.
4. If Product.purchase looks like below, policy check is skipped.

update :purchase

If Product.purchase looks like below, policy check is not skipped.

update :purchase do
  require_atomic? false
end

If I comment out require_atomic? false in my Product.purchase action, the test fails.

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.

Fixed in ash_postgres version 2.4.10

Is it really that “rare” case?
I think policy can check resource’s own field only,
so empty action could be exist often for policy check.

Is there anything I can do instead of Product.purchase empty action in above example?

Can you tell me what is fixed exactly?
I cannot find anything related in ash_postgres changelog.

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

I’m not sure I understand the question. Does upgrading AshPostgres not solve the issue?