[BUG] HTTP 403 - UnauthorizedBlobOverwrite response while trying to overwrite an ADLS Gen2 directory with Userdelegation SAS token and only with ACLs permissions

[GaneshMSFT]

API Spec link

https://learn.microsoft.com/en-us/rest/api/storageservices/datalakestoragegen2/path/create?view=rest-storageservices-datalakestoragegen2-2019-12-12

API Spec version

2023-08-03

Describe the bug

I have a service principal (SPN) that was granted the Storage Blob Delegator role at the account level to obtain a User Delegation Key (Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey). I assigned only ACLs (no data-level RBAC permissions) to my SPN to traverse through the container and directories. Using SPN credentials, I generated a User Delegation SAS token and used it to create a directory under my storage container.

Here is the permission structure for my SPN:

• Account level RBAC: "Storage Blob Delegator"
• Container name: "aclvsrbac" --> R-X
• Directory name: "test" --> R-X
• Sub-directory name: "testdir" --> RWX

With these permissions, I was able to create a directory (testdir2) under "testdir". The initial call to create a directory was successful with an HTTP 201 status. However, subsequent calls with the same SAS token failed with a 403 – UnauthorizedBlobOverwrite error when the "If-None-Match" header was set to "*". I expected an HTTP 409 - The specified path already exists error instead.

I need clarification from the Azure product team on why this behavior differs when using ACLs versus RBAC (storage blob data-level roles).

I want to add that this issue isn't only scoped for directory creation. Its also the similar for blob creation. We recomend customers to use ACLs for fine grain control of permissions but this discrepency in HTTP response code makes it hard for clients to troubleshoot/audit these kind of issues.

Expected behavior

The subsequent CreatePath calls using the same user delegation SAS token with "If-None-Match" header set to "*" should result in HTTP 409 The specified path already exists instead of HTTP 403 - UnauthorizedBlobOverwrite.

Actual behavior

Behaviour when only ACL permissions were given to SPN

Initial call to create a directory

Sub-sequent call failing with 403 - UnAuthorizedBlobOverwrite instead of 409 - The path already exists

When SPN was given Blob Data level roles

When my SPN was given "Storage Blob Data Contributor role" and generated user delegation SAS token following was the behaviour and its expected.

Initial call

Sub-sequent call (409 returned as expected)

Reproduction Steps

# Define the tenant ID for the Azure Active Directory
$tenantId = "<replace tenant id>"

# Define the client ID for the Azure AD application
$clientId = "<replace client id>"

# Define the client secret for the Azure AD application
$clientSecret = "<replace client secret>"

# Convert the client secret to a secure string
$secureClientSecret = ConvertTo-SecureString $clientSecret -AsPlainText -Force

# Create a credential object using the client ID and secure client secret
$credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $clientId, $secureClientSecret

# Connect to Azure using the service principal credentials and tenant ID
Connect-AzAccount -ServicePrincipal -Credential $credential -Tenant $tenantId

# Create a storage context using the connected account and the specified storage account name
$ctx = New-AzStorageContext -StorageAccountName ganeshmstrggen2 -UseConnectedAccount

# Generate a SAS token for the specified storage container with read, add, create, write, delete, and list permissions, valid for up to 7 days from the current UTC time
New-AzStorageContainerSASToken -Context $ctx -Name "aclvsrbac"  -Permission racwdl -ExpiryTime "<Upto 7 days from UTC current time>"

Environment

No response