Файлы не должны быть общедоступными

Обновлено: 03.07.2024

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

Ранее внешним хранилищем назывался раздел диска на съемном носителе, таком как SD-карта (также известном как переносное устройство). Это различие уже неактуально, так как устройства Android существенно изменились и многие устройства Android больше не поддерживают съемные носители. Вместо этого некоторые устройства будут выделять часть внутренней энергонезависимой памяти, которую Android использует для выполнения той же функции съемного носителя. Это называется эмулированным хранилищем и по-прежнему считается внешним. Кроме того, у некоторых устройств Android может быть несколько внешних разделов хранилища. Например, в планшете Android (помимо его внутреннего хранилища) может быть эмулированное хранилище и один или несколько слотов для SD-карты. Все эти разделы рассматриваются Android как внешнее хранилище.

На устройствах с несколькими пользователями у каждого пользователя будет выделенный каталог в основном разделе внешнего хранилища для внешнего хранилища. Приложения, в которых работает один пользователь, не будут иметь доступа к файлам другого пользователя на устройстве. Файлы для всех пользователей по-прежнему будут доступны всем для чтения и записи. Тем не менее, Android будет изолировать каждый профиль пользователя от других.

В этом руководстве описываются основные понятия и API в Android, относящиеся к внешнему хранилищу.

Общедоступные и частные файлы во внешнем хранилище

Существует два разных типа файлов, которые приложение может хранить во внешнем хранилище:

Частные файлы — это файлы, зависящие от приложения (но все еще доступные всем для чтения и записи). В Android предполагается, что частные файлы хранятся в определенном каталоге во внешнем хранилище. Несмотря на то, что файлы называются "частными", они по-прежнему видимы и доступны для других приложений на устройстве, Android не предоставляет им специальные меры защиты.

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

Частные внешние файлы

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

В этом документе будут ссылки на каталог хранилища частных файлов во внешнем хранилище как на PRIVATE_EXTERNAL_STORAGE.

Параметр для GetExternalFilesDir() представляет собой строку, которая указывает каталог приложения. Этот каталог предназначен для стандартного расположения в логической организации файлов. Строковые значения доступны через константы класса Android.OS.Environment :

Android.OS.Environment	Каталог
DirectoryAlarms	PRIVATE_EXTERNAL_STORAGE/Alarms
DirectoryDcim	PRIVATE_EXTERNAL_STORAGE/DCIM
DirectoryDownloads	PRIVATE_EXTERNAL_STORAGE/Download
DirectoryDocuments	PRIVATE_EXTERNAL_STORAGE/Documents
DirectoryMovies	PRIVATE_EXTERNAL_STORAGE/Movies
DirectoryMusic	PRIVATE_EXTERNAL_STORAGE/Music
DirectoryNotifications	PRIVATE_EXTERNAL_STORAGE/Notifications
DirectoryPodcasts	PRIVATE_EXTERNAL_STORAGE/Podcasts
DirectoryRingtones	PRIVATE_EXTERNAL_STORAGE/Ringtones
DirectoryPictures	PRIVATE_EXTERNAL_STORAGE/Pictures

Для устройств с несколькими разделами во внешнем хранилище каждый раздел будет содержать каталог, предназначенный для частных файлов. Метод Android.Content.Context.GetExternalFilesDirs(string type) возвращает массив Java.IO.Files . Каждый объект будет представлять частный каталог приложения для всех совместно используемых устройств с внешними хранилищами, где приложение может размещать принадлежащие ему файлы.

Точный путь к частному каталогу внешнего хранилища может отличаться в зависимости от устройства и версии Android. По этой причине приложения не должны жестко задавать путь к этому каталогу. Вместо этого они должны использовать API-интерфейсы Xamarin.Android, например Android.Content.Context.GetExternalFilesDir() .

Общедоступные внешние файлы

Общедоступные файлы — это файлы, которые существуют во внешнем хранилище и не хранятся в каталоге, который Android выделяет для частных файлов. Общедоступные файлы не удаляются при удалении приложения. Приложения Android должны получить разрешение, прежде чем они смогут считывать или записывать любые общедоступные файлы. Общедоступные файлы могут существовать везде во внешнем хранилище, но по соглашению в Android предусматривается, что общедоступные файлы будут существовать в каталоге, указанном свойством Android.OS.Environment.ExternalStorageDirectory . Это свойство будет возвращать объект Java.IO.File , который представляет основной каталог во внешнем хранилище. В качестве примера Android.OS.Environment.ExternalStorageDirectory может ссылаться на следующий каталог:

В этом документе будут ссылки на каталог хранилища общедоступных файлов во внешнем хранилище как на PUBLIC_EXTERNAL_STORAGE.

Android также поддерживает концепцию каталогов приложений для PUBLIC_EXTERNAL_STORAGE. Эти каталоги в точности совпадают с каталогами приложений для PRIVATE_EXTERNAL_STORAGE и описаны в таблице в предыдущем разделе. Метод Android.OS.Environment.GetExternalStoragePublicDirectory(string directoryType) возвращает объект Java.IO.File , который соответствует общедоступному каталогу приложения. Параметр directoryType является обязательным и не может иметь значение null .

Например, вызов Environment.GetExternalStoragePublicDirectory(Environment.DirectoryDocuments).AbsolutePath вернет строку, которая будет выглядеть так:

Точный путь к общедоступному каталогу во внешнем хранилище может отличаться в зависимости от устройства и версии Android. По этой причине приложения не должны жестко задавать путь к этому каталогу. Вместо этого они должны использовать API-интерфейсы Xamarin.Android, например Android.OS.Environment.ExternalStorageDirectory .

Работа с внешним хранилищем

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

Каждая из этих двух задач будет описана ниже.

Проверка доступности внешнего хранилища

Первым действием перед записью во внешнее хранилище является проверка его доступности для чтения или записи. Свойство Android.OS.Environment.ExternalStorageState содержит строку для определения состояния внешнего хранилища. Это свойство будет возвращать строку, которая представляет состояние. Эта таблица представляет собой список значений ExternalStorageState , которые могут быть возвращены Environment.ExternalStorageState :

ExternalStorageState	Описание
MediaBadRemoval	Носитель внезапно удален без отключения надлежащим образом.
MediaChecking	Носитель присутствует, но проходит проверку диска.
MediaEjecting	Носитель пребывает в процессе отключения и извлечения.
MediaMounted	Носитель подключен, в нем можно выполнять операции чтения и записи.
MediaMountedReadOnly	Носитель подключен, но в нем можно выполнять только операции чтения.
MediaNofs	Носитель присутствует, но не содержит файловой системы, подходящей для Android.
MediaRemoved	Носитель отсутствует.
MediaShared	Носитель присутствует, но не подключен. Его использует через USB-порт другое устройство.
MediaUnknown	Состояние носителя не распознано Android.
MediaUnmountable	Носитель присутствует, но его не удалось подключить к Android.
MediaUnmounted	Носитель присутствует, но отключен.

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

Разрешения внешнего хранилища

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

Все приложения Android должны объявить одно из двух разрешений для внешнего хранилища в AndroidManifest.xml. Чтобы определить разрешения, один из следующих двух элементов uses-permission должен быть добавлен в AndroidManifest.xml:

Если пользователь предоставил разрешение WRITE_EXTERNAL_STORAGE , то также неявно предоставляется и READ_EXTERNAL_STORAGE . Нет необходимости запрашивать оба разрешения в AndroidManifest.xml.

Разрешения также можно добавить на вкладке Манифест Android в разделе свойств решения:

Разрешения также можно добавить с помощью вкладки Манифест Android на панели свойств решения:

В общем, все опасные разрешения подлежат одобрению пользователем. Разрешения для внешнего хранилища являются аномалией в том смысле, что есть исключения из этого правила в зависимости от версии Android, на которой работает приложение:

В этой статье мы расскажем, как использовать Cache-Control . Большинство современных сайтов используют Cache-Control для управления кэшированием браузеров.

Основные принципы использования заголовка Cache-Control

Заголовок Cache-Control определяет количество времени, которое файл должен находиться в кэше, и метод кэширования:

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

В качестве примера можно привести логотип сайта. Если посетитель заходит на одну страниц ресурса, он загружает логотип. Если пользователь переходит на другую страницу, изображение логотипа не будет загружаться снова. Вместо этого будет использоваться кэширование через htaccess .

Что такое max-age?

max-age определяет время, в течение которого файл должен храниться в кэше.

Директива ответа max-age указывает, что ответ следует считать устаревшим после того, как проходит больше времени, чем заданное количество секунд.

Применение max-age

Часть заголовка max-age выглядит следующим образом:

Значение max-age задается в секундах.

Часто используемые значения для max-age :

Одна минута: max-age=60 ;
Один час: max-age=3600 ;
Один день: max-age=86400 ;
Одна неделя: max-age=604800 ;
Один месяц: max-age=2628000 ;
Один год: max-age=31536000 .

При применении max-age для определения времени, которое файл должен храниться в кэше, следует учитывать тип этого файла и то, как он используется.

Директивы кэширования

Часть директивы кэширования в браузере htaccess приведенного выше заголовка выглядит следующим образом:

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

Мы рассмотрим три основные директивы Cache-Control :

public

Официальная спецификация определяет ее следующим образом:

Если вы хотите использовать кэширование для ускорения загрузки страницы, и этот ресурс не является частным, то нужно применить директиву public .

private

Директива private означает, что ресурс предназначается только для конкретного пользователя. В качестве примера можно привести страницу Twitter . Когда вы заходите в Twitter , вы видите одно, а другой человек, открывающий тот же URL-адрес , видит другое содержимое. Даже если информация на этой странице общедоступна, она « специфична » для конкретного человека.

Официальная спецификация определяет ее следующим образом:

no-store

Директива no-store является самым категоричным запретом на кэширование. Официальная спецификация определяет ее следующим образом:

Еще раз отмечу, что само по себе это ничего не гарантирует.

Типы файлов

Два вопроса, которые должен задать себе веб-мастер:

Какие типы файлов нужно хранить с помощью кэширования файлов htaccess?
Как долго их нужно хранить в кэше?

Какие типы файлов должны храниться в кэше?

Я хотел бы отметить следующие типы файлов:

Что следует учесть

Только вы можете определить, какие инструкции больше всего подходят для вашего сайта. Если вы собираетесь изменить какой-либо ресурс ( например, файл CSS ), и этот ресурс кэшируется в браузере htaccess , то стоит подумать над тем, чтобы изменить имя файла. Тогда обновленный файл CSS будет просмотрен всеми пользователями. Это называется URL-дактилоскопией .

Как добавить Cache-Control на сайт

Cache -Control добавляется к файлам точно так же, как любой другой заголовок на вашем сервере. В этой статье мы говорим о заголовке Cache-Control . Так как его добавить? Это зависит от вашего веб-сервера. Мы рассмотрим наиболее распространенные сценарии.

Файл .htaccess

Большинство использует для добавления заголовков файл .htaccess .

Пример кода файла .htaccess

Общий код для установки заголовка Cache-Control с помощью файла .htaccess :

Но приведенный выше код не позволяет задавать различные инструкции кэширования сайта htaccess для различных типов файлов.

Чтобы применить разные заголовки Cache-Control к различным типам файлов, мы будем использовать:

Приведенный выше код означает следующее:

Предположим, что мы хотим изменить время кэширования изображений на один год, но оставить для файлов CSS и JS срок хранения один месяц.

Мы можем добавить в файл .htaccess следующий код:

Приведенный выше код состоит из двух блоков: один для изображений и один для CSS и JS-файлов . У нас может быть несколько блоков в файле .htaccess .

Более быстрым и предпочтительным способом является установка заголовков с помощью конфигурационного файла. Примеры кода, приведенные выше для htaccess кэширования , будут работать и здесь.

Используйте сочетание filesMatch и Header , чтобы создать отдельные инструкции для конкретных типов файлов ( примеры кода для файла .htaccess подходят ).

NGINX

Используя директивы expires, можно добавить инструкции кэширования в блоки сервера или местоположения:

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

Litespeed

Если есть лицензия на несколько процессоров, то вы должны иметь доступ к расширенным директивам кэширования через онлайн-конфигурацию.

Если у вас нет лицензии, то необходимо будет использовать кэширование сайта htaccess . Приведенные выше инструкции для использования в .htaccess подходят также и для серверов Litespeed .

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

Если у файлов на сервере не установлены соответствующие права, то злоумышленник может получить доступ к файлам и сайту.

В этой статье вы узнаете о правах доступа, и как их использовать для увеличения безопасности сайта.

Установка достаточных прав не поможет спастись от всех атак, но сделает сайт гораздо более защищенным. Используйте этот способ защиты сайта вместе с другими способами.

Что такое права доступа

Права доступа состоят из 3-х цифр:

Каждой цифре соответствует действие или несколько действий:

Например, право доступа 644 означает, что у Пользователя есть право читать и записывать в файл информацию, у Группы есть право просматривать файл, и у Мира есть право просматривать файл.

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

Права доступа к этому файлу будут 764.

Если вы смотрите на файлы через FTP или SSH, права доступа выглядят по-другому, :

Буквы означают действия: r = read (чтение), w = write (запись), x = execute (исполнение).

Какие права доступа дать файлам и папкам

Минимальные права, рекомендованные Кодексом Вордпресс:

Для некоторых файлов и папок можно установить более сильные ограничения:

Права доступа к файлам есть только на Linux и Unix серверах, на серверах Windows их нет.

Как изменить права доступа

1. Можно автоматически установить права доступа ко всем файлам и папкам в файле wp-config.php:

Не забудьте изменить права доступа к файлу wp-config.php на 400 или 440.

2. Зайдите в файл-менеджер на хостинг-панели:

Нажмите правой кнопкой на папке или файле, выберите Изменить атрибуты:

На других хостингах может быть другой интерфейс, но делается аналогично.

Поставьте галочки, числовое значение изменится автоматически, и наоборот.

find /путь/к/вашей/папке/ -type d -exec chmod 755 <> \;

Замените /путь/к/вашей/папке/ и /путь/к/вашему/файлу/ на свой адрес. В этом примере папка получила права доступа 755, файл получил права доступа 644.

На просторах России много фирм и мелких предприятий не имеют в штате своего системного администратора на постоянной основе или приходящего время от времени. Фирма растёт и рано или поздно одной расшаренной папки в сети, где каждый может делать что захочет, становится мало. Требуется разграничение доступа для разных пользователей или групп пользователей на платформе MS Windows. Линуксоидов и опытных админов просьба не читать статью.

Самый лучший вариант - взять в штат опытного админа и задуматься о покупке сервера. Опытный админ на месте сам решит: поднимать ли MS Windows Server с Active Directory или использовать что-то из мира Linux.

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

Прежде чем начать хотелось бы разжевать пару моментов:

Любая операционная система "узнаёт" и "различает" реальных людей через их учётные записи. Должно быть так: один человек = одна учётная запись.
В статье описывается ситуация, что в фирме нет своего админа и не куплен, к примеру, MS Windows Server. Любая обычная MS Windows одновременно обслуживает по сети не более 10 для WinXP и 20 человек для Win7. Это сделано фирмой Microsoft специально, чтобы клиентские Windows не перебегали дорогу серверам Windows и вы не портили бизнес Microsoft. Помните число 10-20 и когда в вашей фирме будет более 10-20 человек, вам придётся задуматься о покупке MS Windows Server или попросить кого-либо поднять вам бесплатный Linux Samba сервер, у которого нет таких ограничений.
Раз у вас нет грамотного админа, то ваш обычный комп с клиентской MS Windows будет изображать из себя файловый сервер. Вы вынуждены будете продублировать на нём учётные записи пользователей с других компьютеров, чтобы получать доступ к расшаренным файлам. Другими словами, если есть в фирме ПК1 бухгалтера Оли с учётной записью olya, то и на этом "сервере" (именую его в дальнейшем как WinServer) нужно создать учётную запись olya с таким же паролем, как и на ПК1.
Люди приходят и уходят. Текучесть кадров есть везде и если вы, тот бедный человек, который не админ и назначен (вынужден) поддерживать ИТ вопросы фирмы, то вот вам совет. Делайте учётные записи, не привязанные к личности. Создавайте для менеджеров - manager1, manager2. Для бухгалтеров - buh1, buh2. Или что-то подобное. Ушёл человек? Другой не обидится, если будет использовать manager1. Согласитесь это лучше, чем Семёну использовать учётную запись olya, так как влом или некому переделывать и уже всё работает 100 лет.
Забудьте такие слова как: "сделать пароль на папку". Те времена, когда на ресурсы накладывался пароль давным давно прошли. Поменялась философия работы с различными ресурсами. Сейчас пользователь входит в свою систему с помощью учётной записи (идентификация), подтверждая себя своим паролем (аутентификация) и ему предоставляется доступ ко всем разрешённым ресурсам. Один раз вошёл в систему и получил доступ ко всему - вот что нужно помнить.
Желательно выполнять нижеперечисленные действия от встроенной учётной записи Администратор или от первой учётной записи в системе, которая по умолчанию входит в группу Администраторы.

Приготовление.

В Проводнике уберите упрощённый доступ к нужным нам вещам.

MS Windows XP. Меню Сервис - Свойства папки - Вид. Снять галочку Использовать мастер общего доступа
MS Windows 7. Нажмите Alt. Меню Сервис - Параметры папок - Вид. Снять галочку Использовать простой общий доступ к файлам.

Создайте на вашем компьютере WinServer папку, которая будет хранить ваше богатство в виде файлов приказов, договоров и так далее. У меня, как пример, это будет C:\dostup\. Папка обязательна должна быть создана на разделе с NTFS.

Доступ по сети.

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

И самое главное! Выдать папку в доступ с полным разрешением для всех! Да да! Вы не ослышались. А как же разграничение доступа?

Мы разрешаем по локальной сети всем подсоединяться к папке, НО разграничивать доступ будем средствами безопасности, сохраняемые в файловой системе NTFS, на которой расположена наш каталог.

MS Windows XP. На нужной папке (C:\dostup\) правой клавишей мыши и там Свойства. Вкладка Доступ - Открыть общий доступ к этой папке. Заполняем Примечание. Жмём Разрешение. Группа Все должна иметь по сети право Полный доступ.
MS Windows 7. На нужной папке (C:\dostup\) правой клавишей мыши и там Свойства. Вкладка Доступ - Расширенная настройка. Ставим галочку Открыть общий доступ к этой папке. Заполняем Примечание. Жмём Разрешение. Группа Все должна иметь по сети право Полный доступ.

Пользователи и группы безопасности.

Нужно создать необходимые учётные записи пользователей. Напоминаю, что если на многочисленных ваших персональных компьютерах используются различные учётные записи для пользователей, то все они должны быть созданы на вашем "сервере" и с теми же самыми паролями. Этого можно избежать, только если у вас грамотный админ и компьютеры в Active Directory. Нет? Тогда кропотливо создавайте учётные записи.

MS Windows XP. Панель Управления - Администрирование - Управление компьютером.
Локальные пользователи и группы - Пользователи. Меню Действие - Новый пользователь.
MS Windows 7. Панель Управления - Администрирование - Управление компьютером.
Локальные пользователи и группы - Пользователи. Меню Действие - Создать пользователя.

Теперь очередь за самым главным - группы! Группы позволяют включать в себя учётные записи пользователей и упрощают манипуляции с выдачей прав и разграничением доступа.

Чуть ниже будет объяснено "наложение прав" на каталоги и файлы, но сейчас главное понять одну мысль. Права на папки или файлы будут предоставляться группам, которые образно можно сравнить с контейнерами. А группы уже "передадут" права включённым в них учётным записям. То есть нужно мыслить на уровне групп, а не на уровне отдельных учётных записей.

MS Windows XP. Панель Управления - Администрирование - Управление компьютером.
Локальные пользователи и группы - Группы. Меню Действие - Создать группу.
MS Windows 7. Панель Управления - Администрирование - Управление компьютером.
Локальные пользователи и группы - Группы. Меню Действие - Создать группу.

Нужно включить в нужные группы нужные учётные записи. Для примера, на группе Бухгалтеры правой клавишей мыши и там Добавить в группу или Свойства и там кнопка Добавить. В поле Введите имена выбираемых объектов впишите имя необходимой учётной записи и нажмите Проверить имена. Если всё верно, то учётная запись изменится к виду ИМЯСЕРВЕРА\учётная_запись. На рисунке выше, учётная запись buh3 была приведена к WINSERVER\buh3.

Итак, нужные группы созданы и учётные записи пользователей включены в нужные группы. Но до этапа назначения прав на папках и файлах с помощью групп хотелось бы обсудить пару моментов.

Стоит ли заморачиваться с группой, если в ней будет одна учётная запись? Считаю, что стоит! Группа даёт гибкость и маневренность. Завтра вам понадобится ещё одному человеку Б дать те же права, что и определённому человеку с его учётной записью А. Вы просто добавите учётную запись Б в группу, где уже имеется А и всё!

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

Права доступа.

Желательно выполнять нижеперечисленные действия от встроенной учётной записи Администратор или от первой учётной записи в системе, которая по умолчанию входит в группу Администраторы.

Вот и добрались до этапа, где непосредственно и происходит магия разграничения прав доступа для различных групп, а через них и пользователям (точнее их учётным записям).

Итак, у нас есть директория по адресу C:\dostup\, которую мы уже выдали в доступ по сети всем сотрудникам. Внутри каталога C:\dostup\ ради примера создадим папки Договора, Приказы, Учёт МЦ. Предположим, что есть задача сделать:

папка Договора должна быть доступна для Бухгалтеров только на чтение. Чтение и запись для группы Менеджеров.
папка УчётМЦ должна быть доступна для Бухгалтеров на чтение и запись. Группа Менеджеров не имеет доступа.
папка Приказы должна быть доступна для Бухгалтеров и Менеджеров только на чтение.

На папке Договора правой клавишей и там Свойства - вкладка Безопасность. Мы видим что какие-то группы и пользователи уже имеют к ней доступ. Эти права были унаследованы от родителя dostup\, а та в свою очередь от своего родителя С:

Мы прервём это наследование прав и назначим свои права-хотелки.

Жмём кнопку Дополнительно - вкладка Разрешения - кнопка Изменить разрешения.

Сначала прерываем наследование прав от родителя. Снимаем галочку Добавить разрешения, наследуемые от родительских объектов. Нас предупредят, что разрешения от родителя не будут применяться к данному объекту (в данном случае это папка Договора). Выбор: Отмена или Удалить или Добавить. Жмём Добавить и права от родителя останутся нам в наследство, но больше права родителя на нас не будут распространяться. Другими словами, если в будущем права доступа у родителя (папка dostup) изменить - это не скажется на дочерней папке Договора. Заметьте в поле Унаследовано от стоит не унаследовано. То есть связь родитель - ребёнок разорвана.

Теперь аккуратно удаляем лишние права, оставляя Полный доступ для Администраторов и Система. Выделяем по очереди всякие Прошедшие проверку и просто Пользователи и удаляем кнопкой Удалить.

Кнопка Добавить в данном окне Дополнительные параметры безопасности предназначена для опытных админов, которые смогут задать особые, специальные разрешения. Статья же нацелена на знания опытного пользователя.

Мы ставим галочку Заменить все разрешения дочернего объекта на разрешения, наследуемые от этого объекта и жмём Ок. Возвращаемся назад и снова Ок, чтобы вернуться к простому виду Свойства.

Данное окно позволит упрощённо достигнуть желаемого. Кнопка Изменить выведет окно "Разрешения для группы".

Жмём Добавить. В новом окне пишем Бухгалтеры и жмём "Проверить имена" - Ок. По умолчанию даётся в упрощённом виде доступ "на чтение". Галочки в колонке Разрешить автоматически выставляются "Чтение и выполнение", "Список содержимого папки", "Чтение". Нас это устраивает и жмём Ок.

Теперь по нашему техническому заданию нужно дать права на чтение и запись для группы Менеджеры. Если мы в окне Свойства, то снова Изменить - Добавить - вбиваем Менеджеры - Проверить имена. Добавляем в колонке Разрешить галочки Изменение и Запись.

Теперь нужно всё проверить!

Следите за мыслью. Мы приказали, чтобы папка Договора не наследовала права от свого родителя dostup. Приказали дочерним папкам и файлам внутри папки Договора наследовать права от неё.

На папку Договора мы наложили следующие права доступа: группа Бухгалтеры должна только читать файлы и открывать папки внутри, а группа Менеджеры создавать, изменять файлы и создавать папки.

Следовательно, если внутри директории Договора будет создаваться файл-документ, на нём будут разрешения от его родителя. Пользователи со своими учётными записями будут получать доступ к таким файлам и каталогам через свои группы.

Зайдите в папку Договора и создайте тестовый файл договор1.txt

На нём щелчок правой клавишей мыши и там Свойства - вкладка Безопасность - Дополнительно - вкладка Действующие разрешения.

Жмём Выбрать и пишем учётную запись любого бухгалтера, к примеру buh1. Мы видим наглядно, что buh1 получил права от своей группы Бухгалтеры, которые обладают правами на чтение к родительской папке Договора, которая "распространяет" свои разрешения на свои дочерние объекты.

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

Абсолютно так же, по аналогии с папкой Договора, накладываются права доступа и для других папок, следуя вашему техническому заданию.

Используйте разделы NTFS.
Когда разграничиваете доступ на папки (и файлы), то манипулируйте группами.
Создавайте учётные записи для каждого пользователя. 1 человек = 1 учётная запись.
Учётные записи включайте в группы. Учётная запись может входить одновременно в разные группы. Если учётная запись находится в нескольких группах и какая-либо группа что-то разрешает, то это будет разрешено учётной записи.
Колонка Запретить (запрещающие права) имеют приоритет перед Разрешением. Если учётная запись находится в нескольких группах и какая-либо группа что-то запрещает, а другая группа это разрешает, то это будет запрещено учётной записи.
Удаляйте учётную запись из группы, если хотите лишить доступа, которого данная группа даёт.
Задумайтесь о найме админа и не обижайте его деньгами.

Задавайте вопросы в комментариях и спрашивайте, поправляйте.

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

Читайте также: