minio / minio-dotnet

MinIO Client SDK for .NET
https://docs.min.io/docs/dotnet-client-quickstart-guide.html
Apache License 2.0
565 stars 226 forks source link

PutObjectAsync doesn't handle an 'Access Denied' specific case after upgrade to 6.0.3 #1131

Open marwa-elfakir-logi opened 3 months ago

marwa-elfakir-logi commented 3 months ago

When using version 6.0.3 of the Minio .NET package, a specific behavior related to checking access key policy seems to have changed compared to version 6.0.0.

Here's my function when i upload a file :

`public async Task UploadFileInMinioTest(string serializedJson) { try { //minioClient var minio = new MinioClient() .WithEndpoint("127.0.0.1:9000") .WithCredentials("4AQJCzaLOlAUhaF1WLYK", "8iLGYuCUCf0ARrbY80F0y98HXMvCdTtyy3uNgEFx") .WithSSL(false) .Build();

    //check if bucket exists
    var args1 = new BucketExistsArgs().WithBucket("bkt-test");
    var found = await minio.BucketExistsAsync(args1).ConfigureAwait(false);

    if (found)
    {
        // Convert JSON string to a byte array
        byte[] byteArray = System.Text.Encoding.UTF8.GetBytes(serializedJson);
        using (MemoryStream stream = new MemoryStream(byteArray))
        {
            PutObjectArgs putObjectArgs = new PutObjectArgs()
                                              .WithBucket("bkt-test")
                                              .WithObject("Input/test.json")
                                              .WithContentType("application/json")
                                              .WithStreamData(stream)
                                              .WithObjectSize(stream.Length);

            var response = await minio.PutObjectAsync(putObjectArgs);
        }
    }
}
catch (MinioException ex)
{
    _logger.Error(ex, new FormattedString($"MinioService => UploadFileInMinio : An error occurred during the upload of the file"));
    throw ex;
}
catch (Exception ex)
{
    _logger.Error(ex, new FormattedString($"MinioService => UploadFileInMinio : An error occurred during the upload of the file"));
    throw ex;
}

}`

and here's my access key policy

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucketMultipartUploads", "s3:GetBucketLocation", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::bkt-test" ] }, { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": [ "arn:aws:s3:::bkt-test/input/*" ] }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::bkt-test/*" ] } ] }

As you can see, when it comes to uploading objects (PutObject) only folder 'input' within my bucket is allowed.

When I was using version 6.0.0, and trying to upload file in folder 'Input' (testing case sensitivity) => PutObjectAsync threw a MinioException with Access Denied message which is the expected behaviour in this case.

image

But when I upgraded to version 6.0.3, I no longer receive an "Access Denied" error as expected. This behavior makes it seem that the upload has succeeded, despite it not being the case.

marwa-elfakir-logi commented 3 months ago

Update => while using version 6.0.3 : Instead of receiving the "Access Denied" error in my case, I noticed that the response returned by PutObjectAsync contains Etag == null => Would it be safe to always check on Etag value and consider the upload successful only if it's not null ?

image

ebozduman commented 2 months ago

@marwa-elfakir-logi ,

This behavior you observed was because of a regression bug introduced 6.0.1 and I think PR https://github.com/minio/minio-dotnet/pull/1141 has fixed it. I appreciate if you could test and verify the fix which has not been merged yet. So, you need to sync with the PR branch. Please let me know if you can test the fix and verify that you see the AccessDenied exception again the same way as before.