java.nio.file.attribute

Интерфейсный AclFileAttributeView

Все Суперинтерфейсы:

AttributeView, FileAttributeView, FileOwnerAttributeView

public interface AclFileAttributeView
extends FileOwnerAttributeView

Представление атрибута файла, которое поддерживает чтение или обновление Списков управления доступом файла (ACL) или атрибуты владельца файла.

ACLs используются, чтобы определить права доступа к объектам файловой системы. ACL является упорядоченным списком access-control-entries, каждое определение a UserPrincipal и уровень доступа для того пользовательского принципала. Это представление атрибута файла определяет getAcl, и setAcl методы, чтобы читать и записать ACLs основанный на модели ACL, определенной в RFC 3530: Сетевая файловая система (NFS) Протокол версии 4. Это представление атрибута файла предназначается для реализаций файловой системы, которые поддерживают модель ACL NFSv4 или имеют четко определенное отображение между моделью ACL NFSv4 и моделью ACL, используемой файловой системой. Детали такого отображения являются зависящими от реализации и являются поэтому неуказанными.

Этот класс также расширяется FileOwnerAttributeView чтобы определить методы, чтобы получить и установить владельца файла.

Когда файловая система обеспечивает доступ к ряду file-systems это не является гомогенным тогда, только некоторые из файловых систем могут поддерживать ACLs. supportsFileAttributeView метод может использоваться, чтобы протестировать, если файловая система поддерживает ACLs.

Функциональная совместимость

RFC 3530 учитывает специальные пользовательские идентификационные данные, которые будут использоваться на платформах, которые поддерживают POSIX определенные права доступа. Специальные пользовательские идентификационные данные"OWNER@", "GROUP@", и"EVERYONE@". Когда оба AclFileAttributeView и PosixFileAttributeView поддерживаются тогда, эти специальные пользовательские идентификационные данные могут быть включены в ACL entries это читается или пишется. Файловая система UserPrincipalLookupService может использоваться, чтобы получить a UserPrincipal представлять эти специальные идентификационные данные, вызывая lookupPrincipalByName метод.

Пример использования: Предположите, что мы хотим добавить запись в существующий ACL, чтобы предоставить "joe" доступ:

     // lookup "joe"
     UserPrincipal joe = file.getFileSystem().getUserPrincipalLookupService()
         .lookupPrincipalByName("joe");

     // get view
     AclFileAttributeView view = Files.getFileAttributeView(file, AclFileAttributeView.class);

     // create ACE to give "joe" read access
     AclEntry entry = AclEntry.newBuilder()
         .setType(AclEntryType.ALLOW)
         .setPrincipal(joe)
         .setPermissions(AclEntryPermission.READ_DATA, AclEntryPermission.READ_ATTRIBUTES)
         .build();

     // read ACL, insert ACE, re-write ACL
     List<AclEntry> acl = view.getAcl();
     acl.add(0, entry);   // insert before any DENY entries
     view.setAcl(acl);
 

Динамический Доступ

Где динамический доступ к атрибутам файла требуется, атрибуты, поддерживаемые этим представлением атрибута, следующие:

Имя	Ввести
"acl"	List<AclEntry>
"владелец"	UserPrincipal

getAttribute метод может использоваться, чтобы считать ACL или атрибуты владельца как будто, вызывая getAcl или getOwner методы.

setAttribute метод может использоваться, чтобы обновить ACL или атрибуты владельца как будто, вызывая setAcl или setOwner методы.

Установка ACL, создавая файл

Реализации, поддерживающие это представление атрибута, могут также поддерживать установку начального ACL, создавая файл или каталог. Начальный ACL может быть обеспечен для методов такой как createFile или createDirectory как FileAttribute с name "acl:acl" и a value это - список AclEntry объекты.

Где реализация поддерживает модель ACL, которая отличается от NFSv4, определенная модель ACL, тогда устанавливающая начальный ACL, создавая файл, должна преобразовать ACL в модель, поддерживаемую файловой системой. Методы, которые создают файл, должны отклонить (бросая IOException) любая попытка создать файл, который был бы менее безопасным в результате преобразования.

С тех пор:

1.7

Сводка метода

Методы

Модификатор и Тип	Метод и Описание
List<AclEntry>	getAcl() Читает список управления доступом.
Строка	name() Возвращает имя представления атрибута.
void	setAcl(List<AclEntry> acl) Обновления (замена) список управления доступом.

Методы, наследованные от интерфейса java.nio.file.attribute.FileOwnerAttributeView

getOwner, setOwner

Деталь метода

имя

String name()

Возвращает имя представления атрибута. У представлений атрибута этого типа есть имя "acl".

Определенный:

name в интерфейсе AttributeView

Определенный:

name в интерфейсе FileOwnerAttributeView

getAcl

List<AclEntry> getAcl()
                      throws IOException

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

Когда файловая система использует модель ACL, которая отличается от NFSv4 определенная модель ACL, тогда этот метод возвращает ACL, который является преобразованием ACL к модели ACL NFSv4.

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

Возвраты:

упорядоченный список entries представление ACL

Броски:

IOException - если ошибка ввода-вывода происходит

SecurityException - В случае провайдера по умолчанию устанавливается менеджер безопасности, и это отрицает RuntimePermission("accessUserInformation") или checkRead метод отрицает доступ для чтения к файлу.

setAcl

void setAcl(List<AclEntry> acl)
            throws IOException

Обновления (замена) список управления доступом.

Где файловая система поддерживает Списки управления доступом, и она использует модель ACL, которая отличается от NFSv4 определенная модель ACL, тогда этот метод должен преобразовать ACL в модель, поддерживаемую файловой системой. Этот метод должен отклонить (бросая IOException) любая попытка записать ACL, который, казалось бы, сделал бы файл более безопасным чем, будет иметь место, был ли ACL обновлен. Где реализация не поддерживает отображение AclEntryType.AUDIT или AclEntryType.ALARM записи, тогда этот метод игнорирует эти записи при записи ACL.

Если запись ACL содержит a user-principal это не связывается с тем же самым провайдером как это представление атрибута тогда ProviderMismatchException бросается. Дополнительная проверка допустимости, если таковые вообще имеются, является зависящей от реализации.

Если файловая система поддерживает другую безопасность связанные атрибуты файла (такие как файл access-permissions например), обновление списка управления доступом может также заставить их безопасность связанные атрибуты быть обновленными.

Параметры:

acl - новый список управления доступом

Броски:

IOException - если ошибка ввода-вывода происходит, или ACL недопустим

SecurityException - В случае провайдера по умолчанию устанавливается менеджер безопасности, это отрицает RuntimePermission("accessUserInformation") или checkWrite метод отрицает доступ для записи к файлу.