Page 57 - 2578
P. 57
програмі може призвести до того, що "зловмисник" зможе
змусити її виконати ще якісь дії, не передбачені автором
програми. До речі, більшість відомих способів "зламу"
системи полягають не в тім, щоб довідатися пароля 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-системах він
означає, що, коли файли створюються в такій директорії, в
їхніх атрибутах проставляється та сама група, що й у
56