Титла: chown Permission denied
Публикувано от: Hapkoc в Mar 07, 2006, 15:11
$ cd
$ mkdir test
$ ls -ld test
drwxrwxr-x 2 sasoiliev sasoiliev 4096 Mar 7 15:10 test
$ chown root test
chown: changing ownership of `test': Operation not permitted
Някой може ли да ми даде обяснение защо след като съм собственик на директорията test не мога да променя собственика й?
Това още отпреди ме мъчи ама сега пак изскочи и реших накрая да подпитам.
Поздрави
$ mkdir test
$ ls -ld test
drwxrwxr-x 2 sasoiliev sasoiliev 4096 Mar 7 15:10 test
$ chown root test
chown: changing ownership of `test': Operation not permitted
Някой може ли да ми даде обяснение защо след като съм собственик на директорията test не мога да променя собственика й?
Това още отпреди ме мъчи ама сега пак изскочи и реших накрая да подпитам.
Поздрави
Титла: chown Permission denied
Публикувано от: romeo_ninov в Mar 07, 2006, 15:30
| Цитат |
Only the root user can change the owner of a file. You can change the group of a file only if you are a root user or if you own the file. If you own the file but are not a root user, you can change the group only to a group of which you are a member. |
man chown (AIX)
Титла: chown Permission denied
Публикувано от: ohubohu в Mar 07, 2006, 16:13
| Цитат (romeo_ninov @ Март 07 2006,16:30) | ||
man chown (AIX) |
Romeo е бил доста лаконичен
Наркос, представи си, че това е позволено от системата. Къде, според теб, би отишла сигурността? Нали ако смениш owner_a после и файла (програмата) ще се изпълнява с правата на новия потребител. А ако той е root (както е в твоя пример)?
Титла: chown Permission denied
Публикувано от: Hapkoc в Mar 07, 2006, 17:21
| Цитат |
| Only a privileged process (Linux: one with the CAP_CHOWN capability) may change the owner of a file. The owner of a file may change the group of the file to any group of which that owner is a member. A privileged process (Linux: with CAP_CHOWN) may change the group arbitrarily. |
До това стигнах след малко консултации.
Интересното е, че това го пише в chown(2), но на gentoo, докато на Fedora Core 4 chown(2) страницата е от 1997-05-18 (Linux 2.1.81).
Иначе да, след малко размисли си е съвсем резонно да е така...
Титла: chown Permission denied
Публикувано от: Hapkoc в Mar 07, 2006, 17:23
ohubohu, това с изпълнението не важи ли само ако е suid?
/bin/ls не е ли собственост на root? и като пуснеш с нормален потребител /bin/ls с root права ли се изпълнява?
/bin/ls не е ли собственост на root? и като пуснеш с нормален потребител /bin/ls с root права ли се изпълнява?
Титла: chown Permission denied
Публикувано от: GoodT в Mar 07, 2006, 19:21
#ls -l
-r-xr-xr-x 1 root ...... ls
трипъл Х какво означава
не се изпълнява с root права ,а се изпълнява самата програмата - в случая може всеки да я изпълни.
това ,че е на root означава ,че ТОЙ може да я променя- както самата програма така и правата за достъп до нея.
-r-xr-xr-x 1 root ...... ls
трипъл Х какво означава
не се изпълнява с root права ,а се изпълнява самата програмата - в случая може всеки да я изпълни.
това ,че е на root означава ,че ТОЙ може да я променя- както самата програма така и правата за достъп до нея.
Титла: chown Permission denied
Публикувано от: George Andonov в Mar 08, 2006, 10:31
| Цитат (GoodT @ Март 07 2006,20:21) |
| #ls -l -r-xr-xr-x 1 root ...... ls трипъл Х какво означава не се изпълнява с root права ,а се изпълнява самата програмата - в случая може всеки да я изпълни. това ,че е на root означава ,че ТОЙ може да я променя- както самата програма така и правата за достъп до нея. |
Трите Х-са означават, че всеки може да изпълни програмата. Но програмата се изпълнява с правата на потребителя който я е стартирал. т.е. една и съща програма, стартирана от Иван и Пешо, ще даде различни резултати.
Това е важно: стартиращият, а не собственика.Изключение: Само програмите със SetUser/GroupID се изпълняват с правата на собственика.
Титла: chown Permission denied
Публикувано от: GoodT в Mar 08, 2006, 12:58
Ами точно това казах.
Обаче в отговор на "/bin/ls не е ли собственост на root? и като пуснеш с нормален потребител /bin/ls с root права ли се изпълнява?"
Не споменах за SUID програмите - това наистина трябва да се знае.
Обаче в отговор на "/bin/ls не е ли собственост на root? и като пуснеш с нормален потребител /bin/ls с root права ли се изпълнява?"
Не споменах за SUID програмите - това наистина трябва да се знае.
Титла: chown Permission denied
Публикувано от: Hapkoc в Mar 08, 2006, 13:27
Еми аз с цитираните въпроси именно на тази мисъл исках да наведа колегата ohubohu, че програмата се изпълнява с правата на потребителя, който я е стартирал, а не с правата на собственика, освен в случаите на suid.
Някой има ли идея (освен в случая със suid) има ли други такива случаи, в които смяната на собственика на файла да представлява опасност от гледна точка на сигурността?
Естествено нямам предвид опасност от рода файл с поверителна информация да се направи четим за всички и от тоя род неща, понеже това така или иначе може да стане и без да се сменя собственика и се прави с chmod.
Въпроса ми е - ако имаме файл, който не е suid и приемем на теория, че собственика на файла е непривилегирован потребител и може да промени собственика - при такава ситуация какви опасности може да има по отношение на сигурността?
пример (той като горния почти де):
----
$ cd
$ touch file
$ ls -l file
-rw-r--r-- 2 user users 4096 Mar 7 15:10 file
$ chown anotheruser file # тук приемаме, че това е позволена операция
$
----
От момента на промяна на собственика какви опасности може да има за сигурността на системата? Аз лично не се сещам.
Някой има ли идея (освен в случая със suid) има ли други такива случаи, в които смяната на собственика на файла да представлява опасност от гледна точка на сигурността?
Естествено нямам предвид опасност от рода файл с поверителна информация да се направи четим за всички и от тоя род неща, понеже това така или иначе може да стане и без да се сменя собственика и се прави с chmod.
Въпроса ми е - ако имаме файл, който не е suid и приемем на теория, че собственика на файла е непривилегирован потребител и може да промени собственика - при такава ситуация какви опасности може да има по отношение на сигурността?
пример (той като горния почти де):
----
$ cd
$ touch file
$ ls -l file
-rw-r--r-- 2 user users 4096 Mar 7 15:10 file
$ chown anotheruser file # тук приемаме, че това е позволена операция
$
----
От момента на промяна на собственика какви опасности може да има за сигурността на системата? Аз лично не се сещам.
Титла: chown Permission denied
Публикувано от: в Mar 08, 2006, 16:03
Прави сте за SUID, извинете ме че не съм отговорил - работа 
.
Когато имасх вдигнат S флага, тогава заимстваш правата на собственика на програмата, в останалите случаи - не.
Идеята беше, в по-горния отговор, че ако можеш да направиш "S" (а ти можеш когато си собственик) и после "шитнеш" файла на root, има начин системата да бъде излъгана да запаси SUID бита.
Между другото, ако не се лъжа, казуса се разглежда в един от курсовете за UNIX, не не съм 100% сигурен. Ще се опитам да проверя, но няма да е сега, че се забози една система и м* си е*
. Когато имасх вдигнат S флага, тогава заимстваш правата на собственика на програмата, в останалите случаи - не.
Идеята беше, в по-горния отговор, че ако можеш да направиш "S" (а ти можеш когато си собственик) и после "шитнеш" файла на root, има начин системата да бъде излъгана да запаси SUID бита.
Между другото, ако не се лъжа, казуса се разглежда в един от курсовете за UNIX, не не съм 100% сигурен. Ще се опитам да проверя, но няма да е сега, че се забози една система и м* си е*
Титла: chown Permission denied
Публикувано от: Hapkoc в Mar 08, 2006, 16:34
Да де ясно. На мене последното ми питане е принципно, понеже ако suid е единствения частен случай на възможни проблеми със сигурността при chown, тогава би трябвало да може лесно да се направи една проверка и само в случай, че suid е сетнат за файла, който се опитваш да chown-неш тогава да не ти разрешава, а във останалите случаи да е полволено да chown-неш файл, който си е твой...
Титла: chown Permission denied
Публикувано от: Hapkoc в Mar 08, 2006, 17:33
btw, от chown(2)
| Цитат |
| When the owner or group of an executable file are changed by a non-super-user, the S_ISUID and S_ISGID mode bits are cleared. |