2 Порядок виконання роботи

1 Підімкніться до комп’ютера під керуванням ОС UNIX за допомогою telnet (“Пуск\Виконати\telnet ip”, де ip — адреса машини під керуванням Unix).

2 Після підімкнення введіть ім’я (login) та пароль (password).

3 Запустіть і “вбийте” програму mc:

На першому вікні запустіть програму mc (для цього наберіть mc).

Перейдіть на другу консоль (“Пуск\Виконати\telnet ip”, де ip — адреса машини під керуванням Unix).

На другому вікні введіть власні login та password.

На другому вікні наберіть команду ps і запам’ятайте PID програми mc (PIDmc).

На другому вікні наберіть kill PIDmc (де PIDmc — ідентифікатор mc).

На другому вікні запустіть ps для перевірки результату.

4 Змініть пріоритет існуючого процесу:

На першому вікні запустіть програму mc (для цього наберіть “mc”).

На другому вікні наберіть ps –U st* -all (Виведіть на термінал список усіх процесів користувача st*, де * — номер комп’ютера, за яким працює студент).

Запам’ятайте PID програми mc (PIDmc).

На другому вікні наберіть renice +10 PIDmc.

На другому вікні перевіримо зміну пріоритету ps -U st* -all.

На другому вікні наберіть kill PIDmc.

5 Запустіть процес з потрібним пріоритетом:

На першому вікні наберіть nice +15 deco.

На другому вікні перевіримо зміну пріоритету ps -U st* -all.

На другому вікні наберіть kill PIDmc.

3 Контрольні запитання

1 Що таке PID та UID?

2 У яких станах може перебувати процес?

3 Чому рекомендують давати сигнал HUP перед надсиланням сигналу KILL?

4 У яких межах змінюється відносний пріоритет у системі FreeBSD?

5 Які опції команди ps вам відомі?

Лабораторна робота № 6 права доступу в операційній системі unix

Мета: набуття базових знань стосовно прав доступу в ОС UNIX, набуття практичних навичок щодо використання командних ресурсів за зміни прав доступу до файлів та директорій.

Тривалість роботи – 2 години

1 Основні теоретичні відомості

Поняття прав доступу користувача

Будь-яка Unix-подібна ОС, і зокрема FreeBSD, є система багатокористувацька, у ній передбачено механізм, який обмежує доступ користувачів до файлів та директорій. Природно, "доступ" означає не лише можливість читати чи змінювати вміст окремих файлів, але й можливість створювати файли (директорії), вилучати їх, запускати файли, якщо вони є виконувані, змінювати їхні назви, а також змінювати всі ті атрибути, що й визначають "право доступу", тобто — "хто саме й що саме" може чинити з даним файлом чи директорією.

Насамперед слід зазначити, що слушніше говорити не про "права користувача" стосовно певного файла, а про "права процесу" чи виконуваної програми. По-перше, якщо користувач і вносить певні зміни в файли або директорії, він це здійснює за допомогою певних програм (редакторів, "командерів", системних утиліт для копіювання, вилучення файлів тощо). По-друге, не всі програми запускаються користувачами "вручну". Деякі з них (демони) запускаються при стартуванні системи. Інші можуть запускатися в певні моменти часу, наприклад за допомогою програми cron, чи викликатися в міру необхідності для обслуговування запитів, які надходять мережею (зазвичай їх запускає програма-"диспетчер" inetd). Окрім того, існує низка програм, які для виконання певних допоміжних дій самі запускають інші програми, в цьому разі говорять, що процес-"батько" запустив процес-"нащадок". Зрозуміло, що цим програмам (процесам) слід обмежити доступ до файлів. І, врешті, по-третє, у певних випадках є надто корисно, щоби програма, запущена користувачем, мала більше прав, аніж зазвичай має цей користувач. Приміром, звичайний користувач не може навіть читати файл, у якому "заховано" паролі всіх користувачів. Водночас будь-який користувач має мати можливість змінювати свій особистий пароль, не звертаючись для цього до адміністратора, але для цього йому треба мати можливість записати дещо у файл паролів. Отже, програма, котра це здійснює (passwd), в момент виконання має мати права набагато більші, аніж користувач, котрий її запускає.

Отже:

- кожен процес має ідентифікатор користувача (userID); зазвичай він збігається з usеrID того користувача, котрий запустив цей процес;

- процеси, запущені автоматично, теж мають userID, начебто їх запустив реальний користувач; чий саме userID одержують ці програми, зазвичай визначається тими програмами, які стартують: програмою-завантажувачем, cron, inetd тощо; у найпростіших випадках програми-"нащадки" лише "успадковують" userID від програми-"батька", але деякі "батьки" можуть запускати програми з іншим userID, котрий не збігається з власним;

- деякі програми в процесі виконання можуть змінювати свій userID і, відповідно, набувати прав, яких сам користувач не мав. Природно, для того, щоби програма могла це здійснити, адміністратор має "дозволити" їй таке поводження (докладніше про це буде сказано нижче). До речі, зміна usеrID здійснюється не лише коли потрібно "розширити" права програми, але й навпаки — "звузити" їх до прав певного конкретного користувача;

- якщо процес може змінювати свій userID, то розрізнюють "реальний userID" та "ефективний userID" (є ще "збережений userID"). Реальний userID — це ідентифікатор користувача, котрий запустив процес (або userID процесу-"батька"). А ефективний — це новий userID, якого задача одержала під час виконання;

- права на файл (чи директорію) визначаються за "ефективним userID" процесом. У найпростішому випадку, коли userID не змінюється, "реальний" та "ефективний" usеrіD збігаються — і можна говорити лише про usеrID чи процес, навіть лише про права користувача (а не процесу) на файл.

Усі користувачі для кожного файла (чи директорії) поділяються на три категорії:

— власник (чи хазяїн) цього файла;

— група "особливо допущених" до цього файла;

— вся решта.

Це означає, що можна установити три різних "допуски" (набору прав доступу) для кожного файла чи директорії. Один такий набір визначатиме права користувача, котрий є власником файла; інший набір визначатиме права для користувачів, котрі входять у певну групу, але не є власниками, і, врешті, третій набір установлює права для всієї решти користувачів, котрі не входять у цю групу "особливо допущених" і не є власниками файла. Отже, у кожного файла (директорії) є три атрибути, які зберігаються десь у заголовку файла і також регулюють доступ до нього. Звичайно, атрибутів у файлі є не три, а більше. До атрибутів можна віднести ім’я файла, його обсяг, час створення тощо. Але в даному разі нас цікавлять лише ці три.

У заголовок файла записується ідентифікатор користувача userID, який вважається його власником. При цьому "хазяїном" може бути лише один певний користувач. Окрім того, як атрибут записується ідентифікатор групи (groupID), котрий і визначає ту групу "особливо допущених", про яку йшлося вище. Кожна така група (її назва, числовий ідентифікатор — groupID і склад) визначається адміністратором системи. Тобто "пересічний" користувач, навіть якщо він і є хазяїном файла, не може довільно скласти список "близьких друзів", яким він довіряє особливі права стосовно свого файла. Він може лише обрати придатну групу з наявних тільки якщо він сам входить у цю групу. В атрибутах файла є певний набір бітів чи "прапорців", який і зазначає — хто саме й що саме може чинити з цим файлом. Цей набір називається permissions, що можна перекласти як "допуски", чи "права на доступ".

При наборі команди ls –l на моніторі висвітлюється:

-rw-r--r-- st1 wheel 4297 23мар 17:37 list_us

-rwxr-xr-x st1 wheel 1502 17мар 12:03 myProg

-rw-r--r-- st1 wheel 5354 12мар 23:51 tmp.dat

\_______/ \_____/ \______/ \_______/ \___________/ \________/

"права" власник група довжина дата, час ім’я файла

У другому стовпчику подано ім’я (login name) користувача — "власника" цих файлів (у даному разі це – st1). У третьому стовпчику — назва групи, приписаної також до цих файлів (у даному разі — wheel). У першому стовпчику набір знаків типу "r" (читання), "w" (запис) та "-" (нічого) зазначає можливості для всіх трьох категорій користувачів. Слід зауважити, що в самому заголовку файла зберігаються не імена користувачів та груп, а їхні числові номери, а "права" насправді являють собою не ланцюжок літер, а набір бінарних бітів. Просто команда ls зображує їх у більш узвичаєному вигляді.

Основні біти доступу (читання/запис/виконання)

Розгляньмо докладніше, що являють собою "права доступу". При роздрукуванні вмісту директорії (наприклад командою ls) кожен рядок має вигляд

-rw-r--r-- root wheel 178 Mar 19 21:58 io.c

Причому нас цікавить у даному разі лише перший стовпчик. Він складається з десяти символів. Однак перший символ не має відношення до permissions, а позначає "тип цього об’єкта". У директорії, окрім файлів, можуть міститися піддиректорії, інші об’єкти – “лінки”, ”черги”, “сокети”, котрі мають такі самі атрибути, як і у звичайних файлів. Тому перший символ саме й зазначає, що за об’єкт ми спостерігаємо: звичайний файл (позначка "-"), піддиректорію (позначка "d") чи ще якийсь специфічний об’єкт ("l", "s", "p"...).

Інші дев’ять знаків насправді являють собою три групи по три символи. Кожна така група визначає права для якоїсь із трьох категорій користувачів:

- перша група — права "власника";

- друга група — права "групи особливо допущених";

- третя група — права для "всієї решти".

Зміст окремих бітів у кожної такої групи "прав" є однаковий для всіх трьох категорій користувачів, тому можна докладніше розглядати кожну таку групу, не уточнюючи, для якої саме категорії користувачів вона призначена. Однак для файлів та директорій зміст цих бітів не набагато відрізнюється, тому їх слід розглянути окремо.

При роботі з файлами перший біт позначається літерою "r" (read) і означає, що користувачеві, котрий підпадає під відповідну категорію, дозволяється читати вміст цього файла. Користувач може переглянути вміст файла, а також скопіювати цей файл, але це не означає, що якщо це є програма, то користувач зможе запустити його на виконання. Другий біт позначається літерою "w" (write) і дозволяє запис у файл. Користувач може змінити вміст файла (наприклад котримсь редактором), дописати дещо у кінець або стерти весь вміст. Однак цей біт ще не надає права вилучити сам файл із директорії чи змінити його назву, тому що це визначається правами на саму директорію, але надає можливість зробити цей файл порожнім (нульової довжини) чи скопіювати в нього вміст іншого файла й тим самим "підмінити" його. Третій біт позначається літерою "x" (eXecute), дозволяє запустити на виконання цей файл, якщо він являє собою програму чи командний файл. Часто користувачі-початківці, склавши певний командний файл, забувають установити на нього біт "виконання" хоча б для себе — власника цього файла. Як наслідок, за спроби запустити його, система повідомляє, що "ви не маєте права" виконувати цей файл. Природно, що в даному разі причина полягає не в тім, що "злісний" адміністратор істотно "урізав" права цього користувача, а в тім, що він сам забув "надати собі право", причому цілком законне.

Для директорій перший біт ("r") дозволяє читати зміст цієї директорії, тобто список файлів і піддиректорій, котрі містяться в ній. Однак цей біт ще не надає можливості зайти в цю директорію (командою cd) чи дістати доступ до вмісту, тобто читати, запускати, змінювати файли, навіть якщо "права доступу", установлені на самих файлах, це дозволяють. Тому саме собою "право читання" директорії практично не є чинним і цей біт, як правило, ставиться лише разом з бітами "x". Дещо забігаючи наперед, розглянемо відразу третій біт — "x". Для директорій саме він означає, що користувач може дістати доступ до "компонентів", тобто окремих файлів та піддиректорій. Лише за наявності цього біта система дозволить увійти в цю директорію й виконати певну дію з файлом, якщо самі файли ("права доступу" на них) це дозволять. Треба також звернути увагу, що якщо навіть внутрішні піддиректорії мають "нормальні" права для певної категорії користувачів, а вища директорія — не має, бо відсутній біт "x", то цим користувачам не вдасться "зайти" у піддиректорії, оминаючи вищу. Система перевіряє увесь "шлях" до кінцевої директорії файла (наприклад /usr/share/misc/fonts), і, якщо хоча б один з компонентів цього шляху не має відповідного біта, користувачеві буде відмовлено в доступі. Врешті, біт "w", встановлений на директорії, дозволяє змінювати вміст директорії, тобто дозволяє створювати нові файли (чи копіювати інші файли в цю директорію), змінювати назви файлів і вилучати файли.

Зверніть увагу на "поділ повноважень" поміж тими permissions, що містяться на файлі, й тими, котрі розміщено на директорії.

Як уже зазначалося, якщо права на директорію не дозволяють користувачеві вилучити файл, котрий розміщено в ній, бо немає біта "w", це ще не означає, що користувач не зможе "вилучити вміст" файла, наприклад текстовим редактором. З іншого боку, якщо користувач має право змінювати вміст директорії, він зможе вилучити чи перейменувати кожний файл, котрий вміщено в ній, навіть якщо права на самому файлі не дозволяють йому не те що писати у файл, але й читати його.

Треба також звернути увагу на те, що жодні з перелічених тут прав не мають відношення до змін самих "атрибутів доступу", тобто — власника файла, групи та прав доступу (permissions). Їхня зміна підпорядковується іншим законам, про які йтиметься нижче.

І останнє зауваження. Усі ці біти не мають жодного значення для користувача root (і програм, що під час виконання змінили свій "ефективний userID" на "рутовий"), тобто він може робити з файлом чи директорією все що завгодно. Однак і тут є один виняток. Оскільки біт "x" на файлі є основною ознакою "виконуваності" цього файла, навіть root не зможе переконати систему, що файл є програмою і його можна виконувати, поки не встановить в атрибутах цей біт.

Додаткові біти доступу

Окрім розглянутих вище бітів (читання, запис та "виконуваність"), що встановлюються роздільно по трьох категоріях користувачів, є ще три біти доступу, які можна віднести до файла в цілому, оскільки їхня дія не залежить від того, який користувач, з якої категорії намагається звернутися до файла. Та й призначення цих бітів полягає не в обмеженні доступу до файла чи директорії, а в зміненні певних властивостей файлів директорій.

Біт suid розшифровується як Set user ID, перекладається як "установити ідентифікатор користувача". Оскільки адекватного українського терміна не існує, його зазвичай називають "суїдний" біт, а файли, на яких його установлено— "суїдними". Призначення його полягає в тому, що якщо його установлено на файлі, котрий є програмою, то при виконанні ця програма автоматично змінює "ефективний userID" на ідентифікатор того користувача, котрий є власником цього файла. Тобто, незалежно від того, хто запускає цю програму, вона при виконанні має права хазяїна цього файла. Зазвичай це робиться для того, щоби користувач міг виконати дії, котрі потребýють привілеїв rооt'а (наприклад, змінити свій пароль), а власником такої програми має бути користувач root.

Зрозуміло, що така програма є потенційно "небезпечною". У "нормальному" випадку вона не дозволить звичайному користувачеві зробити те, що виходить за межі його повноважень, наприклад, програма passwd дозволить користувачеві змінити лише власний пароль, але не паролі інших користувачів. Але навіть незначна помилка в такій програмі може призвести до того, що "зловмисник" зможе змусити її виконати ще якісь дії, не передбачені автором програми. До речі, більшість відомих способів "зламу" системи полягають не в тім, щоб довідатися пароля rооt'а, а саме в тім, щоби змусити котрусь із "суїдних" програм виконувати дії, необхідні "зламувачеві". Це не є єдиний шлях змінити "ефективний userID". Це можна зробити із самої програми, викликавши спеціальну системну функцію, але для цього програма має вже мати права rооt'а. Тобто її має запустити користувач root або вона має бути "суїдною", як зазначено вище.

У такого файла permissions виглядають як **s******, якщо ще й встановлено біт x для власника файла, чи як **S******, якщо біт x не встановлено. Однак ставити suid біт на невиконувані файли зазвичай не має сенсу (принаймні в FreeBSD), хоча існують програми, які перевіряють цей біт навіть для текстових файлів. Цей біт не містить жодного значення, якщо його поставити на директорію, хоча ніхто не забороняє це вчинити.

Біт sgid. Розшифровується як Set group ID, перекладається як "установити ідентифікатор групи". Цей зміст є аналогічний змістові попереднього біта, лише змінюється не ідентифікатор користувача, а ідентифікатор групи. Тобто при виконанні цього файла він має такі права, начебто його запустив дехто із групи, приписаної до цього файла.

Permissions такого файла виглядають як *****s*** (якщо встановлено біт x для групи) чи *****S** (якщо відповідного біта x немає). Так само, як і в попередньому випадку, біт sgid для невиконуваних файлів жодного значення не має.

Для FreeBSD (й інших BSD-систем) цей біт, знову ж, не чинить жодної дії. Але в деяких інших Unix-системах він означає, що, коли файли створюються в такій директорії, в їхніх атрибутах проставляється та сама група, що й у директорії. Тобто файли, створювані в такій директорії, "успадковують" групу від директорії.

Біт sticky. У жодний спосіб не розшифровується, перекладається як "липкий". Виглядає в permissions, як ********t, якщо використовується разом з бітом x для "всієї решти" чи як ********T, якщо відповідного біта x немає.

Для директорій його значення полягає в тім, що вилучити файл із такої директорії (чи перейменувати) здатен лише власник файла. В звичайному випадку (без такого біта) можливість вилучати файли (як і створювати) визначається правом запису (біт w) на директорії. Тобто, якщо якийсь користувач належить до категорії, для якої дозволено запис у директорію, він може вилучити в ній який завгодно файл, незалежно від атрибутів (власника, групи, permissions) самого файла.

Застосовують цей біт, зазвичай, на директоріях, які є "публічними" (наприклад /tmp). Такі директорії мають права доступу, котрі дозволяють усім користувачам створювати там свої файли й вилучати їх. Однак було б неправильно, якби кожний інший користувач міг помилково чи "аби нашкодити" вилучати файли, до яких він не має жодного відношення. Для того аби запобігти можливості вилучення файла "стороннім" користувачем, саме і слугує sticky біт. Цей біт може ставитися також на виконувані файли. У цьому разі він означає, що файл, навіть після завершення роботи, має залишатися в пам’яті (не в ОЗУ, а в swap-файлі підкачування, котрий використовується в разі недостачі обсягу ОЗУ й у деяких інших випадках). Це корисно для часто використовуваних файлів загального користування, котрі виконуються. На практиці такі файли зустрічаються не надто часто.

Сполучення бітів доступу

Зазвичай права на файл (наприклад, для "всієї решти") встановлюються в такий спосіб:

--- жодних прав (не можна ані читати, ані змінювати вміст);

--- r-- лише читання;

--- rw- і читання і запис (зміна) файла.

Якщо файл є "виконуваний", то права можуть виглядати так:

--- жодних прав (читати не можна, запускати не можна);

--- r-x можна запустити файл-задачу на виконання;

--- rwx можна не лише запустити, але й дещо у ньому змінити.

Інші сполучення (наприклад -w- чи --x) здаються безглуздими. Однак це не завжди є так. Розглянемо докладніше.

Права -w- означають, що користувач з відповідної категорії не може прочитати цей файл, але може в нього писати.

Для " " файла, що виконується, це сполучення є безглузде (запустити як задачу не можна, але "зіпсувати" щось усередині — будь ласка). Якщо цей файл являє собою щось на зразок "лога" чи поштової скриньки, то такі permissions можуть мати сенс. Наприклад, ви припускаєте, що інші користувачі (чи певні програми-автомати) будуть дописувати сюди свої "повідомлення", але не хочете, щоб ті самі користувачі могли переглянути, що саме туди написали інші. Хоча при цьому ніхто не заважає тим самим користувачам просто, не читаючи, записати в цей файл що-небудь, вилучивши при цьому весь старий вміст файла, чи навіть скопіювати туди файл нульової довжини (чи /dev/null); при цьому, природно, взагалі жодного "вмісту" у файла не стане. Однак, щоби запобігти такій ситуації, можна поставити на той самий файл прапорець "лише дозапис". Він не завадить читати свій файл, а іншим користувачам дописувати в нього що-небудь. Щоправда, й не дасть навіть вам стирати з файла все зайве чи вилучити файл, поки ви не "знімете" прапорець.

Для виконуваних файлів права --x є насправді цілком законна комбінація. Вона означає, що запустити цю задачу можна (і одержати від неї певний результат). Не можна лише скопіювати цей файл собі чи "залізти" у його налагоджувач, саме тому такі permissions є навіть корисні, якщо ви хочете зберегти свою "інтелектуальну власність". Комбінація -wx, мабуть, значення не має, як і просто -w- на файлі, котрий виконується. Ви лише надаєте можливість змінити вміст, причому "наосліп" (оскільки переглянути цей вміст не можна). Результатом може бути лише псування вашого файла. Також можна віднести до безглуздих і права r-- на файлі, що виконується. Якщо ви хочете у такий спосіб "подражнити" когось (от є такий файл, можна подивитися, як його усередині влаштовано, а виконати — не можна), то не зваблюйтеся. Інший користувач спокійно може скопіювати цей файл собі, при цьому він стає повноправним власником отриманої копії. Після цього він поставить на свою копію такі права, які йому заманеться, і, врешті решт, запустить його.

Для директорій зазвичай права доступу встановлюються в такий спосіб:

--- — жодних прав; r-x — нормальні права для "відвідування" директорії, але без права зміни (створювати/вилучати/перейменовувати файли); rwx — повний доступ (чини там що заманеться).

Якщо немає біту доступу --x (доступ до вмісту), то кожна комбінація з двох інших нічого корисного не надасть. Комбінація r-- надасть можливість одержати список файлів у цій директорії, наприклад командою ls, і не більш того. Причому побачити можна буде лише імена файлів, а такі “подробиці”, як власник/група/permissions, будуть неприступні. У таку директорію не можна "увійти" командою cd. І навіть якщо усередині її піддиректорії мають цілком нормальні права доступу (наприклад, r-x), потрапити в них буде неможливо.

Комбінації -w- і rw- мають ще менше сенсу. Все одно, змінити щось у директорії з такими правами доступу не вдасться.

А от сполучення --x і -wx є насправді цілком осмислені. У такий спосіб можна створити "напівсекретну" директорію. "Таємність" її полягає в тім, що ніхто сторонній не зможе переглянути, що за файли й директорії в ній розміщено. Але, якщо ви когось повідомите, як називається файл, що міститься там, його можна без проблем вилучити звідти чи переглянути його безпосередньо на місці.

Аналогічно ведеться і з піддиректоріями. Якщо ви не хочете, щоби хто-небудь, знічев’я "блукаючи" вашими директоріями, натрапив на директорію з "секретним" змістом, але водночас дозволяєте обмеженому колу користувачів знайомитися з новими поповненнями, рекомендується свої приватні директорії розмістити в директорії (наприклад private) з доступом --x. Тоді інші зможуть потрапити в потрібну піддиректорію, указавши повний шлях (cd private/pictures), а випадковий відвідувач її взагалі не віднайде (якщо, звичайно, цей відвідувач не є root). Зрозуміло, "таємність" у цьому разі буде неповною, оскільки, якщо сторонній якимось чином дізнається про правильну назву файла чи піддиректорії, то набуде тих самих можливостей, що й "близькі друзі".

Право -wx відрізняється від попереднього тим, що "довіреним особам" можна писати в цю директорію. Вони можуть скопіювати туди файл, вилучити, якщо, певна річ, знають його точну назву, тощо. Знову ж таки, сторонній зможе хіба що записати туди файл, чого ви не пропонували. Вилучити там що-небудь чи перейменувати, не знаючи назв файлів (і піддиректорій), він не зможе. Отже усім користувачам можуть надаватися такі права:

- власникові — повні права (rwx);

- групі довірених осіб — те ж саме, але без права зміни (r-x);

- всій решті — жодних прав (---).

Зазвичай права призначаються навіть ще простіше. Оскільки групи складають root і пересічні користувачі, здебільшого, не обирають собі сусідів по групі, то їхні файли й директорії мають однакові "допуски" для групи і "всієї решти". Наприклад, для "несекретних" файлів (директорій) - rwxr-xr-x, а ті, котрі власник хоче відокремити від сторонніх, — rwx------.

Але в даному разі йдеться не про це. Що буде, якщо "всій решті" надати доступ, нехай і обмежений, а для групи "особливо наближених" — навпаки, заборонити (виглядати це буде приблизно так: - rwx---r-x)? Тоді група, приписана до файла, перетвориться з групи "особливо допущених" на групу "надто небажаних". Тобто певний "чорний список", куди можна занести (природно, зробити це може лише root) усіх тих, хто не користується довірою. Зверніть увагу, що система, перевіряючи права конкретного користувача стосовно файла, спочатку перевіряє, чи не є він власником, потім — чи не входить він у групу, а вже потому відносить його до "всієї решти". Отже, навіть якщо "вся решта" мають допуск до файла, але користувач мав неприємність потрапити у відповідну групу, до нього застосовуватимуть права доступу групи.