Dotaz: BFU nemůže změnit práva vlastního souboru - temná magie?!

[Franta Hanzlík]

Pokud jsem přihlášen jako běžný (ne root) uživatel, nemohu změnit práva na obyč souboru, jehož jsem vlastníkem - ačkoliv by to IMO jít mělo... Možná pro stromy nevidím les, napadá vás něco?
Shrnu:

• uživatel je vlastníkem souboru i jeho a nadřazeného adresáře
• má práva zápisu do adresáře, v němž soubor je
• skupina souboru není primární skupina uživatele, ale uživatel je členem skupiny, kterou má soubor
• root práva bez problému změní
• pokud jako uživatel soubor zkopíruji do jiného (se zachováním práv, jedno zda do stejného n. jiného adresáře), na kopii práva změnit jdou
• pokud jako uživatel soubor přejmenuji (jde bez problémů), na přejmenovaném práva změnit nejdou
• SELinux je v permissive modu (a kontext se překopíruje)
• na souboru ani jeho adresáři nejsou žádná ACL
• není nastaven immutable flag na souboru ani jeho adresáři
• soubor má user extended attribut (user.DOSATTRIB), ale ten by jednak změně práv bránit neměl, druhak jej má i kopie souboru u které práva změnit jdou
• soubor nemá přiřazeny žádné capabilities (to by bylo vidět i z getfattr)
• soubor není otevřen žádným procesem (ale to by stejně nemělo vadit)
• stejnou chybou ('Operation not permitted') skončí i např. příkaz změny skupiny souboru na prim. skupinu uživatele
• nejedná se o jeden jediný soubor, takových je v adresáři více. Vznikly nejspíš překopírováním z jiného stroje (nejspíš widlí), který měl tenhle adresář připojený jako Samba share.

pár operací/informací okolo problému:

[pc@pepa pokusy]$ pwd
/usr/local/moje/pokusy


[pc@pepa pokusy]$ id
uid=501(pepa) gid=501(pepa) groups=501(pepa),10(wheel),2513(domain users),54323(domainUsers) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023


[pc@pepa pokusy]$ uname -a
Linux pc.kepl.local 4.1.12-124.20.3.el6uek.x86_64 #2 SMP Thu Oct 11 17:47:32 PDT 2018 x86_64 x86_64 x86_64 GNU/Linux


[pc@pepa pokusy]$ ls -lad readme.htm* . ..
drwxrwxrwx. 24 pepa domainUsers 12288 Feb  4 14:54 .
drwxrwsr-x.  5 pepa domainUsers  4096 May 13  2017 ..
-rwxrwxrwx.  1 pepa domainUsers  1016 Jan 10 18:17 readme.htm


[pc@pepa pokusy]$ cp --preserve=all readme.htm readme.html


[pc@pepa pokusy]$ ls -lad readme.htm* . ..
drwxrwxrwx. 24 pepa domainUsers 12288 Feb  4 14:59 .
drwxrwsr-x.  5 pepa domainUsers  4096 May 13  2017 ..
-rwxrwxrwx.  1 pepa domainUsers  1016 Jan 10 18:17 readme.htm
-rwxrwxrwx.  1 pepa domainUsers  1016 Jan 10 18:17 readme.html


[pc@pepa pokusy]$ getfacl readme.htm* . ..
# file: readme.htm
# owner: pepa
# group: domainUsers
user::rwx
group::rwx
other::rwx

# file: readme.html
# owner: pepa
# group: domainUsers
user::rwx
group::rwx
other::rwx

# file: .
# owner: pepa
# group: domainUsers
user::rwx
group::rwx
other::rwx

# file: ..
# owner: pepa
# group: domainUsers
# flags: -s-
user::rwx
group::rwx
other::r-x


[pc@pepa pokusy]$ lsattr -d readme.htm* . ..
-------------e--- readme.htm
-------------e--- readme.html
----------I--e--- .
-------------e--- ..


[pc@pepa pokusy]$ getfattr -d -m "-" readme.htm readme.html . ..
# file: readme.htm
security.selinux="system_u:object_r:usr_t:s0"
user.DOSATTRIB=0sMHgyMAAAAwADAAAAEQAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFXWFG4IqdQBAAAAAAAAAAA=

# file: readme.html
security.selinux="system_u:object_r:usr_t:s0"
user.DOSATTRIB=0sMHgyMAAAAwADAAAAEQAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFXWFG4IqdQBAAAAAAAAAAA=

# file: .
security.selinux="unconfined_u:object_r:usr_t:s0"

# file: ..
security.selinux="unconfined_u:object_r:usr_t:s0"


[pc@pepa pokusy]$ chmod 644 readme.htm readme.html                 <=== tady měním ta práva, na původním i kopii
chmod: changing permissions of `readme.htm': Operation not permitted


[pc@pepa pokusy]$ mv readme.htm Readme.htm


[pc@pepa pokusy]$ chmod 644 Readme.htm                             <=== tady měním práva na přejmenovaném
chmod: changing permissions of `Readme.htm': Operation not permitted


[pc@pepa pokusy]$ chgrp pepa Readme.htm
chgrp: changing group of `Readme.htm': Operation not permitted


[pc@pepa pokusy]$ ls -lad *eadme.htm* . ..
drwxrwxrwx. 24 pepa domainUsers 12288 Feb  4 15:02 .
drwxrwsr-x.  5 pepa domainUsers  4096 May 13  2017 ..
-rwxrwxrwx.  1 pepa domainUsers  1016 Jan 10 18:17 Readme.htm
-rw-r--r--.  1 pepa domainUsers  1016 Jan 10 18:17 readme.html


[pc@pepa pokusy]$ fuser -v Readme.htm 


[pc@pepa pokusy]$ getcap -v *eadme.htm*
Readme.htm
readme.html

---

---

Odpovědi

[debian+]

https://cs.wikipedia.org/wiki/Umask

[debian+]

kukal si aj toto?

[Franta Hanzlík]

Jak jsem psal v dotazu, to "cp --preserve=all _nefungující_   _kopie_" překopíruje i ten user.DOSATTRIB extended atribut - a na tu kopii uživatel chmod i chgrp provede bez problémů, ať to kopíruji do stejného adresáře jako originál, do podadresáře, nebo i úplně mimo strom adresáře, k kterém ten originál je.

[Pavel 'TIGER' Růžička]

Ty ten adresář sdílíš, nebo ne? Když ho překopíruješ v rámci totožné složky, tak práva změnit lze? A po přejmenování už ne? A co parametr +w?

[Franta Hanzlík]

Ten adresář, v kterém jsou tyhle ne-chmod/ne-chgrp -nutelné soubory je do sítě nabízený jako Samba share, jestli myslíš tohle. A jde mi o změnu práv souborů v něm - vezmu nějaký soubor (v příkladu v otázce "readme.htm",
chmod 644 readme.htm
na něm skončí s
"chmod: changing permissions of `readme.htm': Operation not permitted"
Ten soubor (jako uživatel-vlastník) překopíruji na jiný ve stejném adresáři (
cp --preserve=all readme.htm readme.html
) a kopii změním práva (i grupu) bez problémů (ačkoliv práva, ACL, atributy i extended atributy u originálu i kopie jsou napohled stejné).
Stejně tak pokud v daném adresáři založím podadresář a do něj (nebo úplně mimo tenhle strom, viz výše) překopíruji ty soubory, tak se kopie chovají normálně/očekávaně - práva na nich změnit jdou.
Pokud soubor původní soubor, na kterém chmod nejde, přejmenuji na jiný ve stejném adresáři (to jde), tak na něm chmod opět končí s "Operation not permitted". Stejně tak, pokud jej přesunu do podadresáře nebo úplně mimo:

[pc@pepa pokusy]$ chmod 744 Readme.htm 
chmod: changing permissions of `Readme.htm': Operation not permitted

[pc@pepa pokusy]$ mkdir AAA
[pc@pepa pokusy]$ mv Readme.htm AAA/
[pc@pepa pokusy]$ chmod 744 AAA/Readme.htm 
chmod: changing permissions of `AAA/Readme.htm': Operation not permitted

[pc@pepa pokusy]$ mkdir /var/tmp/AAA
[pc@pepa pokusy]$ mv AAA/Readme.htm /var/tmp/AAA/
[pc@pepa pokusy]$ chmod 744 /var/tmp/AAA/Readme.htm 
chmod: changing permissions of `/var/tmp/AAA/Readme.htm': Operation not permitted

Relativně specifikovaná práva se chovají stejně:

[pc@pepa pokusy]$ chmod u+w /var/tmp/AAA/Readme.htm 
chmod: changing permissions of `/var/tmp/AAA/Readme.htm': Operation not permitted

[pc@pepa pokusy]$ chmod g+w /var/tmp/AAA/Readme.htm 
chmod: changing permissions of `/var/tmp/AAA/Readme.htm': Operation not permitted

[pc@pepa pokusy]$ chmod o+w /var/tmp/AAA/Readme.htm 
chmod: changing permissions of `/var/tmp/AAA/Readme.htm': Operation not permitted

[pc@pepa pokusy]$ cp --preserve=all /var/tmp/AAA/Readme.htm /var/tmp/AAA/readme.html
[pc@pepa pokusy]$ chmod o+w /var/tmp/AAA/readme.html

Podle toho, že chmod nejde udělat ani když se soubor přesune jinam, to vypadá na nějakou vlasnost přímo těch souborů...ale jakou?
Hlavička FS (je na něm /, /usr i /var vč. podadresářů) se mi zdá také OK:

# dumpe2fs -h /dev/sda2
dumpe2fs 1.43-WIP (20-Jun-2013)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          726e46ce-0882-4874-a2cb-2bf51753c91a
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
...

Připadám si jako totální debil...

[petr_p]

Vzpomínám si, že existoval pro samba server nějaký bezpečnostní modul do Linuxu, jehož smyslem bylo dělat antivirus. Poslední dobou antiviry dělají všelicos (ochrana před šifrováním). Třeba někoho napadlo, že onen rozšířený atribut bude interpretovat jako soubor jen pro čtení (ta hodnota DOSATTRIB je podezřele dlouhá) a tak odmítá jakékoliv operace na něm. A třeba ten modul je napsaný špatně a místo jen exportovaných podstromů kontroluje úplně všechno.

[Franta Hanzlík]

Zapomněl jsem uvést, že při zastavené Sambě se to chová stejně. A Samba podle konfigurace nemá zavedený vůbec žádný modul, ani z těch v balíčcích běžných (koš, acl, audit, quota,...).
Ta hodnota DOSATTRIB už asi není jen textový výčet DOS atributů:
https://lists.samba.org/archive/samba/2015-August/193472.html
a tady to jsou skoro samé nuly:

$ getfattr -d -e hex -m "-" /var/tmp/AAA/Readme.htm 
getfattr: Removing leading '/' from absolute path names
# file: var/tmp/AAA/Readme.htm
security.selinux=0x73797374656d5f753a6f626a6563745f723a7573725f743a733000
user.DOSATTRIB=0x3078323000000300030000001100000020000000000000000000000000000000000000000000000055d6146e08a9d4010000000000000000

[Pavel 'TIGER' Růžička]

No a když jako root na to hodíš 777, pak to chownem předáš uživateli, tak pak změna práv pod uživatelem nefunguje?

[Pavel 'TIGER' Růžička]

Případně je překopírovat jinam, původní smazat a z kopie je vrátit na původní místo?

[Franta Hanzlík]

To ano, tohle funguje, i to už vyplývá z toho, co jsem o kopírování napsal výše. Přesněji, já ta práva ani jako user měnit nepotřebuji, mohu to udělat jako root, ale když už jsem na to narazil...
Jako nejpravděpodobnější příčinu problému teď vidím chybu jádra jak níže uvádí PetebLazar - jinak si to vysvětlit neumím...

[Franta Hanzlík]

Oni ty práva už 0777 jsou. A když je jako root zadám stejná, uberu, zase přidám - tak uživatelův chmod zase skončí chybou "Operation not permitted".

Bingo! Pokud root změní vlastníka souboru na stejného, tak tomu už chmod funguje:

[pc@pepa pokusy]$ ls -ladi readme.txt 
2234652 -rwxrwxrwx. 1 root domainUsers 2927 May  3  2017 readme.txt

[pc@pepa pokusy]$ chmod 644 readme.txt 
chmod: changing permissions of `readme.txt': Operation not permitted

[pc@pepa pokusy]$ sudo chown abra readme.txt 

[pc@pepa pokusy]$ ls -ladi readme.txt 
2234652 -rwxrwxrwx. 1 abra domainUsers 2927 May  3  2017 readme.txt

[pc@pepa pokusy]$ chmod 644 readme.txt                      <==== tohle už projde OK

Dá se to něčím vysvětlit?

[petr_p]

Tohle se dá vysvětlit jednoduše. Uživatel abra nemůže změnit práva souboru readme.txt, protože ten soubor vlastní root.

Obecně bych ještě viděl možnost, že máte v systému více UID se stejným login name. Zkontrolujte si číslo vlastníka pomocí stat.

[Franta Hanzlík]

Jasně, nevšiml jsem si, omlouvám se, sáhl jsem po špatném souboru. Spěch a nepozornost.

ALE s těmi duplicitními login name - to je trefa do černého!
Je to tak, další účty se získávaly přes winbindd, a tam byl stejný účet mapovaný na jiné UID. Teď je do definitivně jasné. Díky moc!

[petr_p]

Jste si jistý, že se jedná o lokání souborový systém? (Je-li připojen po síti, do výsledku mluví server.) Jste si jistý, že souborový systém není poškozen? Nemáte zaveden nějaký další (než SELinux) bezpečnostní modul? Nemáte rozbitý program chmod? (Výstup nástroje strace souhlasí?) Zkusil jste souborový systém připojit z jiného operačního systému (například z živé distribuce) a zkusit operaci odtamtud?

[Franta Hanzlík]

Lokální FS to je. Je-li poškozen nebo ne - nevím; ale proč by to root-ovi fungovalo? Jádro zná asi jen ten SELinux (/sys/kernel/security/ je prázdný a:

# grep SECURITY /boot/config-$(uname -r)
++ uname -r
+ grep SECURITY /boot/config-4.1.12-124.20.3.el6uek.x86_64
CONFIG_IP_NF_SECURITY=m
CONFIG_IP6_NF_SECURITY=m
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4_FS_SECURITY=y
CONFIG_JFFS2_FS_SECURITY=y
CONFIG_NFS_V4_SECURITY_LABEL=y
CONFIG_NFSD_V4_SECURITY_LABEL=y
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_NETWORK_XFRM=y
# CONFIG_SECURITY_PATH is not set
CONFIG_SECURITY_SECURELEVEL=y
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set
CONFIG_DEFAULT_SECURITY_SELINUX=y
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="selinux"

a SELinux:

# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 29
Policy from config file:        targeted

Rozbitý chmod - "rpm -V coreutils" (ověření balíčku) nehlásí žádnou chybu. A strace vyzerá taky normálně:

$ strace -o /tmp/chmod-strace.lst chmod o+w /var/tmp/AAA/Readme.htm
a výstup:
...
umask(0)                                = 02
stat("/var/tmp/AAA/Readme.htm", {st_mode=S_IFREG|0777, st_size=1016, ...}) = 0
fchmodat(AT_FDCWD, "/var/tmp/AAA/Readme.htm", 0777) = -1 EPERM (Operation not permitted)
...
write(2, "chmod: ", 7)                  = 7
write(2, "changing permissions of `/var/tm"..., 49) = 49
write(2, ": Operation not permitted", 25) = 25
...

Připojit odjinud to nemohu - není to lokální stroj.
Čertví, zdali ti poťouchlíci z Redhatu nepodvrhli Oraclu nějaký špatný patch ;)
Je taky možné, že je to nějaké specifikum toho Unbreacable krámu, žádné větší zkušenosti s tím nemám.

[PetebLazar]

Tady někdo popisuje chybu kernelu zjistenou u 4.4.0 kdy u souboru, které byly chownuty od root na jineho uzivatele nejde pozdeji provest chmod vlastnikem. To by se asi teoreticky sambovskych souboru mohlo tykat (soubor se zalozi vznikne pod rootem a skonci pod vlastnikem:skupinou definovanou v share sekci). Je otazkou za oprava byla (ucinne) backportovana i do 4.1? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1555997

[Franta Hanzlík]

Jo, tohle by mohla být trefa. A jestli jsem tu příčinu chyby pochopil dobře, tak to zmršilo něco v inodu souboru - takže jestliže bylo někdy dříve na systému jádro 4.4.0 s chybou (což je dost pravděpodobné), tak mohlo dojít k namršení těhle souborů - a následný update na jádro bez chyby to už asi nezachránil. Ale pokud root udělal chown zase na stejného vlastníka jako byl předtím, tak se to opravilo a začalo se to chovat správně (jak píši výše v reakci na Pavel 'TIGER' Růžička).
Takže bych to viděl jako vyřešené, díky za pomoc!
(jestli někdo nemá jiný nápad, prosím někoho s právem označit dotaz za vyřešený o příslušný zásah)

[petr_p]

Ale tohle se týká ovelayfs. Nikoliv ext.

[PetebLazar]

Tak to jsem přehlédl. Beru zpět.

Zkusil bych ješte změnit u souboru group na primární skupinu uživatele (tu v /etc/passwd) a vyzkoušel zda potom uživatel bude moci již provést chmod g+w.

[Franta Hanzlík]

Viz výše příspěvek od pert_p - byly dva účty "pepa" s rozdílným UID (jeden lokální a jeden přes winbindd).
Ach jo...
Všem díky za ochotu a pomoc!