База знаний LinxCloud Services

Список управления доступом

Основная информация

С помощью ACL (Access Control List) можно контролировать уровень доступа пользователей как для всего бакета, так и для конктретного объекта.  Автоматически только у владелеца бакета/объекта есть доступ к операциям ним, соттветсвенно у других доступ закрыт. Существует несколько способов, чтобы установить ACL и прочесть его. ACL задается в XML формате, где в поле Owner ID необходимо указать свой канонический идентификатор в системе LinxCloud. Один из способов получения индентификатора:

aws s3api list-buckets --query Owner.ID --output text --endpoint-url https://hb.bizmrg.com

ACL, когда только владелец имеет полный доступ к операциям:

1<?xml version="1.0" encoding="UTF-8"?>
2<AccessControlPolicy xmlns="https://<имя_бакета>.hb.bizmrg.com/images/01.jpg/">
3  <Owner>
4    <ID>fcd68908-6c76-42d1-968b-82ae2a5a251d</ID>
5    <DisplayName>owner-display-name</DisplayName>
6  </Owner>
7  <AccessControlList>
8    <Grant>
9      <Grantee xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
10               xsi:type="Canonical User">
11        <ID>fcd68908-6c76-42d1-968b-82ae2a5a251d</ID>
12        <DisplayName>display-name</DisplayName>
13      </Grantee>
14      <Permission>FULL_CONTROL</Permission>
15    </Grant>
16  </AccessControlList>
17</AccessControlPolicy>

 

  • <Owner> — определяет владельца по каноническому идентификатору пользователя учетной записи LinxCloud.
  • <Grant>— определяет идентификатор получателя, чтобы предоставить разрешение.
  • <Permission> внутри <Grant> — назначает тип доступа для получателя.

По умолчанию ACL имеет один элемент <Grant>, а чтобы описать несколько получателей, необходимо для каждого надо добавить свой элемент <Grant>.

Примечание

ACL может содержать не более 100 разрешений

При установке через HTTP заголовки, нужно использовать заголовки для выдачи специфичных для заголовка прав:

  • x-amz-grant-read — Список получателей прав для READ.
  • x-amz-grant-write — Список получателей прав для WRITE.
  • x-amz-grant-read-acp — Список получателей прав для READ_ACP.
  • x-amz-grant-write-acp — Список получателей прав для WRITE_ACP.
  • x-amz-grant-full-control — Список получателей прав для FULL_CONTROL.
  • x-amz-acl — Использование шаблонного ACL.

Ниже даны описания каждого из прав и что указывать в значениях заголовков.

 

Выдача прав

Существуют несколько типов идентификаторов для выдачи прав:

  • Конкретный пользователь в LinxCloud — необходимо знать его уникальный индентификатор.
  • Проект в LinxCloud — необходимо знать уникальный идентификатор проекта.
  • Предварительно определенные группы — список указан ниже.
  • Весь мир, включая анонимный доступ- для любого, знающего полный адрес до объекта.

Выданное право для идентификатора выше может быть одним или составлено из нескольких типов:

  • READ — только чтение, какие-либо изменения не разрешены.
  • WRITE — только запись, какие-либо чтения не разрешены. Включая удаление.
  • READ_ACP — чтение ACL, какие-либо изменения не разрешены.
  • WRITE_ACP — запись ACL, какие-либо чтения не разрешены. Включая удаление.
  • FULL_CONTROL — все, что перечислено выше, сразу.

 

Выдача прав по идентификатору пользователя

Идентификатор пользователя (он же известен как канонический ID/Canonical ID) — это уникальный идентификатор, состоящий из набора символов. Пример — fcd68908-6c76-42d1-968b-82ae2a5a251d. Формат не фиксирован, при работе с идентификатором пользователя какие-либо преобразования и привязки к формату идентификатора не рекомендуются.

  • Если используется установка через XML, то внутри <Grantee> надо указать тег <ID>.Пример: <ID>fcd68908-6c76-42d1-968b-82ae2a5a251d</ID>
  • Если используется установка через HTTP заголовок, то в значении заголовка надо использовать ключ id.Пример: id="fcd68908-6c76-42d1-968b-82ae2a5a251d".

Канонический ID пользователя учетной записи LinxCloud можно получить, прочитав ACL бакета или объекта, к которому учетная запись LinxCloud имеет права доступа. Когда отдельная учетная запись LinxCloud получает разрешения по запросу на Grant, в ACL добавляется запись гранта с каноническим ID пользователя учетной записи LinxCloud.

Примечание

Если сделать свой бакет общедоступным (не рекомендуется), любой неаутентифицированный пользователь может загружать объекты в бакет. У этих анонимных пользователей нет учетной записи LinxCloud. Когда анонимный пользователь загружает объект в бакет, LinxCloud S3 добавляет специальный канонический ID пользователя (65a011a29cdf8ec533ec3d1ccaae921c) в качестве владельца объекта в ACL.

 

Выдача прав по идентификатору проекта

Если идентификатор пользователя неизвестен, но известен идентификатор проекта, то можно указать проект. При обработке запроса на установку ACL, система ищет идентификатор пользователя и сохраняет его в ACL. В результате ACL всегда будут содержать канонический ID пользователя для проекта, а не идентификатор проекта.

  • Если используется установка через XML, то внутри <Grantee> надо указать тег <EmailAddress>.Пример: <EmailAddress>mcs2400549523</EmailAddress>
  • Если используется установка через HTTP заголовок, то в значении заголовка надо использовать ключ id.Пример: emailAddress="mcs2400549523".

Получить свой идентификатор проекта можно в личном кабинете в области информации об учетной записи. Кнопка, расположенная рядом с идентификатором проекта позволяет скопировать параметр для удобства.

Внимание

При предоставлении другим учетным записям LinxCloud доступ к своим ресурсам, следует учитывать, что учетные записи LinxCloud могут делегировать свои разрешения пользователям под своими учетными записями. Это известно как доступ к нескольким аккаунтам.

 

Выдача предварительно определенным метагруппам

Hotbox имеет набор предопределенных групп. Указывая специальный идентификатор «пользователя», система автоматически подставляет права по правилам, указанным ниже. То, что идентификатор выглядит как ссылка на AWS, не означает, что используются ресурсы AWS S3. Эти идентификаторы обрабатываются только как набор символов и используются для обратной совместимости с программами, которые созданы для AWS S3.

  • Authenticated Users — группа авторизованных пользователей. Эта метагруппа содержит все существующие учетные записи в системе LinxCloud, включая те, которыми вы не можете управлять. Разрешение на доступ к этой группе позволяет любой учетной записи LinxCloud получить доступ к ресурсу. Однако все запросы должны быть подписаны (аутентифицированы). Нужно указывать https://acs.amazonaws.com/groups/global/AuthenticatedUsers в поле URI. Авторизированным пользователям надо подписывать свои запросы для доступа к ресурсу.

Внимание

При предоставлении доступа группе пользователей Authenticated Users, любой авторизованный пользователь LinxCloud из Интернет может получить доступ к ресурсу.

  • All Users — группа «Все пользователи». Эта метагруппа снимает какие-либо ограничения на указанное право. Например, если сделать открытый доступ на READ, то любой пользователь может считывать содержимое, если он знает только имя бакета и имя объекта. А WRITE для всех позволяет любому пользователю все, что это право даёт. Нужно указывать https://acs.amazonaws.com/groups/global/AllUsers в поле URI.

Осторожно!

Убедительно просим взвесить все аргументы в пользу использования метагрупп!

Открывая доступ неопределенному кругу лиц, Вы теряете контроль, кто сможет совершать операции с Вашими ресурсами. Оплата за их действия совершается владельцем бакета. Самый неблагоприятный сценарий — анонимный пользователь с WRITE-доступом удаляет нужные для хранения объекты и размещает терабайты нежелательных файлов другому владельцу бакета.

Анонимные неавторизированные пользователи, если им предоставлен доступ, совершают действия под каноническим ID пользователя 65a011a29cdf8ec533ec3d1ccaae921c, так как у них нет учетной записи в LinxCloud.

  • Если используется установка через XML, то внутри <Grantee> надо указать тег <URI>.Пример: <URI>https://acs.amazonaws.com/groups/global/AllUsers</URI>
  • Если используется установка через HTTP заголовок, то в значении заголовка надо использовать ключ id.Пример: uri="https://acs.amazonaws.com/groups/global/AllUsers"

 

Виды разрешений

В таблице перечислены наборы разрешений, которые LinxCloud S3 поддерживает в ACL. Набор разрешений ACL одинаков для ACL объекта и ACL бакета. Эти ACL предоставляют разрешения для определенных бакетов или операций с объектами. В таблице перечислены разрешения и описано, что они означают в контексте объектов и бакетов.

Разрешение Применение к бакету Применение к объекту
READ
  • HeadBucket
  • GetBucketLifecycle
  • GetBucketNotification
  • ListObjects
  • ListParts
  • ListMultiparts
Позволяет получить содержимое объекта и его метаданные:

  • GetObject
  • HeadObject
  • GetObjectRange
WRITE Позволяет создавать, удалять, перезаписывать любые объекты в бакете:

  • DeleteBucketNotification
  • PutBucketNotification
  • PutBucketLifecycle
  • DeleteBucketLifecycle
  • DeleteObject
  • DeletMultipleObjects
  • AbortMultipart
  • InitMultipart
  • UploadPart
  • CompliteMultipart
  • PutObject
  • PutObjectCopy
Не применимо
READ_ACP Позволяет читать ACL бакета:

  • GetBucketAcl
  • GetBucketCors
Позволяет читать ACL объекта:

GetObjectAcl

WRITE_ACP Позволяет изменять ACL бакета:

  • CreatePrefixKey
  • DeletePrefixKey
  • ListPrefixKeys
  • PutBucketCors
  • DeleteBucketCors
  • PutBucketAcl
Позволяет изменять ACL объекта

PutObjectAcl

FULL_CONTROL Комбинирует права READ, WRITE, READ_ACP, WRITE_ACP для бакета Комбинирует права READ, WRITE, READ_ACP, WRITE_ACP для объекта

 

Сопоставление разрешений ACL и разрешений политики доступа

ACL допускает только конечный набор разрешений по сравнению с количеством разрешений, которые можно установить в политике доступа. Каждое из этих разрешений позволяет выполнять одну или несколько операций LinxCloud S3.

В следующей таблице показано, как каждое разрешение ACL сопоставляется с соответствующими разрешениями политики доступа. Как видно, политика доступа допускает больше разрешений, чем ACL. ACL используется в основном для предоставления базовых разрешений на чтение и запись, аналогично разрешениям файловой системы.

Разрешение ACL Политика доступа для бакета Политика доступа для объекта
READ ListBucket,
ListBucketMultipartUploads
GetObject
WRITE PutObject,
DeleteObject
Не применимо
READ_ACP GetBucketAcl GetObjectAcl
WRITE_ACP PutBucketAcl PutObjectAcl
FULL_CONTROL Эквивалент предоставлению READ, WRITE,
READ_ACP, и WRITE_ACP ACL разрешений
Эквивалент предоставлению READ, READ_ACP и WRITE_ACP ACL разрешений

 

Ключи состояния

При предоставлении разрешения политики доступа, можно использовать условные ключи, чтобы ограничить значение ACL для объекта с помощью политики бакета. Приведенные ниже контекстные ключи соответствуют спискам ACL. Эти контекстные ключи предназначены для указания использования определенного ACL в запросе:

  • s3:x-amz-grant-read — Доступ на чтение
  • s3:x-amz-grant-write — Права записи
  • s3:x-amz-grant-read-acp — Доступ на чтение ACL бакета
  • s3:x-amz-grant-write-acp — Права на запись ACL бакета
  • s3:x-amz-grant-full-control — Полный контроль
  • s3:x-amz-acl — Использование шаблонного ACL

 

Пример ACL

<?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="https://<имя_бакета>.hb.bizmrg.com/images/01.jpg/">
  <Owner>
    <ID>Owner-canonical-user-ID</ID>
    <DisplayName>display-name</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>Owner-canonical-user-ID</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
    
    <Grant>
      <Grantee xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>user1-canonical-user-ID</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>WRITE</Permission>
    </Grant>

    <Grant>
      <Grantee xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xsi:type="CanonicalUser">
        <ID>user2-canonical-user-ID</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>READ</Permission>
    </Grant>

    <Grant>
      <Grantee xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
        <URI>https://acs.amazonaws.com/groups/global/AllUsers</URI> 
      </Grantee>
      <Permission>READ</Permission>
    </Grant>

    <Grant>
      <Grantee xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
        <EmailAddress>project-ID</EmailAddress>
      </Grantee>
      <Permission>READ</Permission>
    </Grant>

 </AccessControlList>
</AccessControlPolicy>

 

Фиксированный ACL

LinxCloud S3 поддерживает набор предопределенных разрешений, известных как стандартные списки ACL. Каждый фиксированный ACL имеет предопределенный набор получателей и разрешений. В следующей таблице перечислены стандартные списки ACL и связанные с ними предопределенные разрешения.

Фиксированный ACL Относится к Разрешения добавлены в ACL
private Бакет и объект Владелец получает FULL_CONTROL. Больше ни у кого нет прав доступа (по умолчанию).
public-read Бакет и объект Владелец получает FULL_CONTROL. Группа AllUsers получает READ доступ.
public-read-write Бакет и объект Владелец получает FULL_CONTROL. Группа AllUsers получает READ и WRITE доступ.
aws-exec-read Бакет и объект Владелец получает FULL_CONTROL.
authenticated-read Бакет и объект Владелец получает FULL_CONTROL. Группа AuthenticatedUsers получает READ доступ.
bucket-owner-read Объект Владелец объекта получает FULL_CONTROL. Владелец бакета получает READ доступ. Если указать этот шаблонный ACL при создании бакета, Linx S3 проигнорирует его.
bucket-owner-full-control Объект И владелец объекта, и владелец бакета получают FULL_CONTROL над объектом. Если указать этот фиксированный ACL при создании бакета, Linx S3 проигнорирует его.

Примечание

В запросе можно указать только один из этих фиксированных списков ACL.

В запросе указывается фиксированный ACL, используя заголовок запроса x-amz-acl. Когда Linx S3 получает запрос со стандартным списком управления доступом в запросе, он добавляет предопределенные разрешения в список управления доступом ресурса.


Также см. полезную статью https://help.icq.net/hotbox-help/advanced/api/acl?ShowDesktopLayout

 

Списки управления доступом (ACL)

Hotbox предоставляет возможность управлять доступом к контейнерам и объектам с помощью списка управления доступа — ACL. У каждого контейнера и объекта есть свой список доступа. Этот список определяет каким проектам или глобальным группам предоставляются права доступа и соответствующие права доступа. При получении запроса на ресурс сервис проверяет соответствующий ACL на наличие прав доступа у запрашивающего.

При создании контейнера или объекта сервис создает стандартный ACL, который предоставляет владельцу ресурса право полного контроля над этим ресурсом, и запрещает доступ остальным проектам и глобальным группам. Это показано в следующем примере ACL бакета (стандартный ACL объекта имеет ту же структуру).

<?xml version=»1.0″ encoding=»UTF-8″?>

<AccessControlPolicy xmlns=»https://BucketName.hb.bizmrg.com/doc/2006-03-01/»>

 <Owner>

 <ID>***Owner-Canonical-User-ID***</ID>

 <DisplayName>owner-display-name</DisplayName>

</Owner>

  <AccessControlList>

    <Grant>

      <Grantee xmlns:xsi=»https://www.w3.org/2001/XMLSchema-instance»

xsi:type=»Canonical User»>

 <ID>***Owner-Canonical-User-ID***</ID>

<DisplayName>owner-display-name</DisplayName>

</Grantee>

      <Permission>FULL_CONTROL</Permission>

 </Grant>

  </AccessControlList>

</AccessControlPolicy>

  • Блок Owner определяет владельца по каноническому идентификатору пользователя проекта и по домену.
  • Блок Grant определяет получателя прав (проект сервиса или глобальную группу) и предоставляемое право доступа.

Базовый ACL содержит один элемент Grant для владельца. Вы можете предоставлять права с помощью добавления элементов Grant, где каждый из них определяет получателя прав и соответствующее право доступа.

Получатель прав

Получателем прав может являться проект сервиса или одна из глобальных групп сервиса. Вы можете предоставлять права проекту сервиса при помощи адреса электронной почты (домена) или канонического идентификатора проекта. При этом если вы указываете адрес электронной почты (домен) в вашем запросе на права доступа, то сервис определяет канонический идентификатор пользователя для соответствующего проекта и добавляет его в ACL. В результате ACL всегда будут содержать канонический идентификатор пользователя для проекта сервиса, а не адрес электронной почты проекта (домен).

Глобальные группы сервиса

У сервиса существует набор предопределенных групп. При предоставлении группе прав доступа к проекту вы указываете один из наших URI вместо канонического идентификатора пользователя. Сервисом предоставляются нижеуказанные глобальные группы.

  • Группа Authenticated Users — группа авторизованных пользователей.

Данная группа представляет собой все проекты сервиса. Наличие права доступа к этой группе позволяет любому проекту сервиса получать доступ к ресурсу. Но в то же время все запросы должны быть подписаны (авторизованы).

  • Группа All Users — группа всех пользователей.

Наличие права доступа к этой группе позволяет всем получать доступ к ресурсу. Запросы могут быть подписанными (авторизованными) или неподписанными (анонимными). В неподписанных запросах отсутствует заголовок аутентификации Authentication в запросе.

При использовании ACL, получателем прав может являться проект сервиса или одна из предопределенных групп сервиса.

Предоставляемые разрешения

Следующая таблица содержит набор разрешений, поддерживаемых сервисом в ACL. Необходимо отметить, что набор разрешений ACL один и тот же для объекта и контейнера (за исключением запрета права WRITE на объекте).Нижеследующие таблицы содержат разрешения и описывают их в контексте разрешений объекта и контейнера.

Разрешение При предоставлении на контейнере При предоставлении на объекте
READ Позволяет получателю прав получить список объектов в контейнере. Позволяет получателю прав прочитать данные объекта и его метаданные.
WRITE Позволяет получателю прав создавать, переписывать и удалять любой объект в контейнере. Неприменимо.
READ_ACP Позволяет получателю прав прочитать ACL контейнера. Позволяет получателю прав прочитать ACL объекта.
WRITE_ACP Позволяет получателю прав записывать ACL для соответствующего контейнера. Позволяет получателю прав записывать ACL для соответствующего объекта.
FULL_CONTROL Дает получателю прав следующие разрешения на контейнер: READ, WRITE, READ_ACP и WRITE_ACP. Дает получателю прав следующие разрешения на объект: READ, READ_ACP и WRITE_ACP.

Соответствие разрешений ACL и разрешений политики доступа

Каждое из прав доступа позволяет провести в сервисе одну или несколько операций. Следующая таблица показывает соответствие прав доступа и операций.

Разрешение ACL Соответствующее разрешение политики доступа при предоставлении разрешения ACL на бакете Соответствующее разрешение политики доступа при предоставлении разрешения ACL на объекте
READ
  • HeadBucket
  • ListMultiparts
  • ListObjects
  • ListParts
  • GetObject
  • HeadObject
WRITE
  • AbortMultipartUpload
  • CompliteMultipartUpload
  • InitiateMultipartUpload
  • UploadPart
  • PutObject
  • DeleteObject
Неприменимо
READ_ACP
  • GetBucketAcl
  • GetObjectAcl
WRITE_ACP
  • PutBucketAcl
  • PutObjectAcl
FULL_CONTROL Эквивалентно предоставлению следующих разрешений ACL: READ, WRITE, READ_ACP и WRITE_ACP. Эквивалентно предоставлению следующих разрешений ACL: READ, READ_ACP и WRITE_ACP.

Связанный ACL

Сервис поддерживает набор предопределенных предоставлений разрешений — так называемых «готовых ACL». Каждый готовый ACL содержит предопределенный набор получателей прав и разрешений. Следующая таблица содержит набор готовых ACL и связанных с ними предопределенных предоставлений разрешений.

Связанный ACL Область применения Добавленные в ACL разрешения
private Контейнер и объект Владелец получает полные права (FULL_CONTROL). Остальные пользователи не получают прав доступа (по умолчанию).
public-read Контейнер и объект Владелец получает полные права (FULL_CONTROL). Группа всех пользователей Allusers получает право доступа на чтение (READ).
public-read-write Контейнер и объект Владелец получает полные права (FULL_CONTROL). Группа всех пользователей AllUsers получает права доступа на чтение (READ) и запись (WRITE). Как правило, не рекомендуется предоставлять данные разрешений на контейнер.
authenticated-read Контейнер и объект Владелец получает полные права (FULL_CONTROL). Группа авторизованных пользователей (AuthenticatedUsers) получает права доступа на чтение (READ).
bucket-owner-read Объект Владелец объекта получает полные права (FULL_CONTROL). Владелец бакета получает права на чтение (READ).
bucket-owner-full-control Объект Владелец объекта и владелец бакета получают полные права (FULL_CONTROL) на объект.

Можно указывать только один из этих связанных ACL в своем запросе  — только при установлении ACL через заголовки

 

Установка ACL

API-сервис позволяет вам установить ACL при создании бакета или объекта. Сервис также предоставляет API для возможности установки ACL на существующем бакете или объекте. Эти API дают возможность устанавливать ACL с помощью нижеуказанных способов.

  • Установка ACL с помощью заголовков запроса — при отправке запроса по созданию ресурса (бакета или объекта) вы устанавливаете ACL при помощи заголовков запроса. Данные заголовки позволяют вам указать или готовый ACL, или установить предоставления разрешений явным образом (однозначно определить получателя прав и разрешения).
  • Установка ACL с помощью тела запроса — при отправке запроса по установке ACL на существующем ресурсе вы можете установить ACL или в заголовке запроса, или в теле.

Обзор особых случаев при установке ACL

Будьте внимательны когда устанавливаете новое право доступа. Политика назначения прав  доступа такова, что установлении прав доступа в некоторых случаях может видоизменяться ваш  ACL.  Например при установлении прав любой глобальной группе будут потеряны все права доступа для отдельных проектов. Чтобы этого не происходило вам нужно устанавливать все права доступа одновременно — только в этом случае утери прав доступа отдельными проектами не происходит

Рассмотрим пример. Вы завели проект client@bizmrg.ru и создали контейнер bucketname. Изначально контейнер частный — только вы имеете к нему доступ.

<?xml version=»1.0″ encoding=»UTF-8″?>
<AccessControlPolicy xmlns=»https://s3.amazonaws.com/doc/2006-03-01/»>
<Owner>
<ID>client_canonical_id</ID>
<DisplayName>client@bizmrg.ru</DisplayName>
</Owner>
<AccessControlList>
<Grant>
<Grantee xmlns:xsi=»https://www.w3.org/2001/XMLSchema-instance»
xsi:type=»Canonical User»>
<ID>client_canonical_id</ID>
<DisplayName>client@bizmrg.ru</DisplayName>
</Grantee>
<Permission>FULL_CONTROL</Permission>
</Grant>
</AccessControlList>
</AccessControlPolicy>

Допустим, вы захотели дать доступ на запись, удаление или перезапись объектов для вашего контейнера bucketname другому проекту friend_project@bizmrg.ru.

<?xml version=»1.0″ encoding=»UTF-8″?>
<AccessControlPolicy xmlns=»https://s3.amazonaws.com/doc/2006-03-01/»>
<Owner>
<ID>***Owner-Canonical-User-ID***</ID>
<DisplayName>owner-display-name</DisplayName>
</Owner>
<AccessControlList>
<Grant>
<Grantee xmlns:xsi=»https://www.w3.org/2001/XMLSchema-instance»
xsi:type=»Canonical User»>
<ID>friend_project_canonical_id</ID>
<DisplayName>friend_project@bizmrg.ru</DisplayName>
</Grantee>
<Permission>WRITE</Permission>
</Grant>
</AccessControlList>
</AccessControlPolicy>

Как вы видите, блок, содержащий ваши данные и предоставляемое право FULL_CONTROL (AccessControlPolicy.AccessControlList.Grant.Grantee, пропал. Однако это не значит что вы как владелец больше не обладаете правом FULL_CONTROL. Вы всегда владеете  этим правом и вас невозможно его лишить.

Данное поведение объясняется лишь синтаксисом ответа ACL, который требует наличие секций (AccessControlPolicy.AccessControlList.Grant.Grantee). Как вы можете заметить, при частном доступе на объекте никаким проектам или глобальным группам права не предоставляются.

Теперь, допустим, вы захотели сделать ваш контейнер публичным для чтения. Для этого есть два пути:

1. Добавить public ACL через заголовки x-amz-acl или x-amz-grant-read или через тело запроса:

 **PUT /?acl HTTP/1.1**
 Authorization: authorization string
 Connection: close
 Date: Wed, 02 Aug 2017 09:53:13 GMT
 Host: bucketname.hb.bizmrg.com
 X-amz-content-sha256: UNSIGNED-PAYLOAD
 X-amz-acl: public-read
 **HTTP/1.1 200 OK**
 Server: nginx/1.12.1
 Date: Wed, 02 Aug 2017 09:53:14 GMT
 Content-Type: text/html; charset=utf-8
 Content-Length: 0
 Connection: close
 X-req-id: iySm3Cph

И тогда запросив ACL на вашем контейнере снова вы увидите:

<?xml version=»1.0″ encoding=»utf-8″?>
<AccessControlPolicy xmlns=»https://s3.amazonaws.com/doc/2006-03-01/»>
   <Owner>
       <ID>client_canonical_id</ID>
       <DisplayName>client@bizmrg.ru</DisplayName>
   </Owner>
   <AccessControlList>
       <Grant>
           <Permission>FULL_CONTROL</Permission>
           <Grantee xmlns:xsi=»https://www.w3.org/2001/XMLSchema-instance» xsi:type=»CanonicalUser»>
               <ID>client_canonical_id</ID>
               <DisplayName>client@bizmrg.ru</DisplayName>
           </Grantee>
       </Grant>
       <Grant>
           <Permission>READ</Permission>
           <Grantee xmlns:xsi=»https://www.w3.org/2001/XMLSchema-instance» xsi:type=»Group»>
               <URI>https://acs.amazonaws.com/groups/global/AllUsers</URI>
           </Grantee>
       </Grant>
   </AccessControlList>
</AccessControlPolicy>

Право WRITE для проекта friend_project@bizmrg.ru исчезло и теперь данный проект не может записывать, удалять, перезаписывать объекты в вашем контейнере. В блоках AccessControlPolicy.AccessControlList.Grant вы увидите информацию о пользователя который установил публичный ACL и сам публичный ACL.

2. Для сохранения прав доступа у проектаfriend_project@bizmrg.ru вам необходимо за один запрос установить права доступа и глобальной группе и вашему пользователю:

 **PUT /?acl HTTP/1.1** Authorization: authorization string
 Connection: close
 Content-Length: 417
 Date: Wed, 02 Aug 2017 09:53:13 GMT
 Host: bucketname.hb.bizmrg.com
 X-amz-content-sha256: UNSIGNED-PAYLOAD

<?xml version=»1.0″ encoding=»utf-8″?>
<AccessControlPolicy>
   <Owner>
       <ID>client_canonical_id1</ID>
       <DisplayName>client@bizmrg.ru</DisplayName>
   </Owner>
   <AccessControlList>
       <Grant>
           <Permission>READ</Permission>
           <Grantee xmlns:xsi=»https://www.w3.org/2001/XMLSchema-instance» xsi:type=»Group»>
               <URI>https://acs.amazonaws.com/groups/global/AllUsers</URI>
           </Grantee>
       </Grant>
       <Grant>
           <Permission>WRITE</Permission>
           <Grantee xmlns:xsi=»https://www.w3.org/2001/XMLSchema-instance» xsi:type=»CanonicalUser»>
               <ID>friend_project_canonical_id</ID>
               <DisplayName>friend_project@bizmrg.ru</DisplayName>
           </Grantee>
       </Grant>
   </AccessControlList>
</AccessControlPolicy>
Что вас интересует?
Получить промокод
остались вопросы?

Закажите консультацию специалиста

заказать тест-драйв
Получить демо-доступ

Спасибо за ваш запрос, мы свяжемся с вами в ближайшее время!