abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 22:22 | Komunita

MojeFedora.cz informuje, že Fedora 31 už pravděpodobně nevyjde v 32bitové variantě. Justin Forbes z Fedora Kernel Teamu navrhl, aby se pro Fedoru 31 už nesestavovaly kernely pro 32bitovou architekturu i686. Znamenalo by to také, že už by nevznikaly bootovatelné obrazy. I nadále by se pro tuto architekturu ale měly sestavovat hlavičkové soubory kernelu a celý userspace, což bude sloužit především k zachování kompatibility na 64bitových systémech.

Ladislav Hagara | Komentářů: 6
25.6. 21:44 | Nová verze

Po roce vývoje od vydání verze 11.0 byla vydána nová verze 12.0 a krátce nato 12.0.1 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností v příspěvku na blogu.

Ladislav Hagara | Komentářů: 0
25.6. 17:00 | Zajímavý článek

Článek na webu OSTechNix ve stručnosti popisuje technologie „balení“ aplikací AppImage, Snap a Flatpak: jejich stěžejní vlastnosti a rozdíly mezi nimi. Text se nezabývá správci balíčků Guix či Nix, ani tradičními distribučními správci balíčků jako APT, YUM aj.

Fluttershy, yay! | Komentářů: 3
25.6. 11:00 | Zajímavý článek

Národní centrum kybernetické bezpečnosti aktualizovalo bezpečnostní doporučení pro síťové správce (pdf). Tato doporučení jsou nastavena tak, aby je bylo možné aplikovat pokud možno v každé instituci. Doporučení jsou opět rozdělena do tří základních částí: bezpečnost infrastruktury, bezpečnost stanic a serverů a bezpečnost uživatelů.

Ladislav Hagara | Komentářů: 10
25.6. 09:11 | Komunita

Nedávno byla představena publikační platforma people.kernel.org. Své zápisky zde mohou publikovat vývojáři jádra Linux. Řešení je postaveno na WriteFreely a Write.as.

Ladislav Hagara | Komentářů: 0
24.6. 12:11 | Nová verze

Byla vydána nová verze 2019-06-20 linuxové distribuce Raspbian určené především pro jednodeskové miniaturní počítače Raspberry Pi. Přehled novinek v příspěvku na blogu a v poznámkách k vydání. Společně s Raspbianem byl aktualizován také instalační nástroj NOOBS (New Out Of the Box Software). Nejnovější verze Raspbianu vychází z Debianu 10 s kódovým názvem Buster a přináší především podporu Raspberry Pi 4 Model B.

Ladislav Hagara | Komentářů: 1
24.6. 10:55 | Zajímavý článek

Vývojáři postmarketOS (GitLab) hodnotí dva roky vývoje tohoto v květnu 2017 představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky [reddit, Hacker News].

Ladislav Hagara | Komentářů: 0
24.6. 10:11 | IT novinky

Nadace Raspberry Pi na svém blogu oficiálně představila (YouTube) jednodeskový počítač Raspberry Pi 4 Model B. K dispozici je ve třech verzích: 1 GB, 2 GB a 4 GB RAM. Cena začíná na 35 dolarech za verzi s 1 GB RAM. Nejnovější Raspberry Pi podporuje 2 monitory a rozlišení 4K.

Ladislav Hagara | Komentářů: 29
23.6. 18:22 | Komunita

Oznámení, že Ubuntu od vydání 19.10 nebude distribuovat 32bitové balíčky (ani multilib) a uživatelé mohou použít virtualizaci či kontejnery LXD, se setkalo s vlnou nevole, mj. protože i řada 64bitových aplikací využívá 32bitový instalátor. Vývojáři Wine a Steamu oznámili, že zřejmě přestanou Ubuntu od vydání 19.10 podporovat. Diskuze na Redditu: [Wine], [Steam].

Fluttershy, yay! | Komentářů: 68
22.6. 16:11 | IT novinky

Nový open source Windows Terminal představený na vývojářské konferenci Microsoft Build 2019 lze již instalovat z Microsoft Store. Podrobnosti v příspěvku na blogu Microsoftu.

Ladislav Hagara | Komentářů: 12
Jakou verzi jádra Linux typicky používáte na osobním počítači?
 (17%)
 (20%)
 (55%)
 (3%)
 (5%)
Celkem 368 hlasů
 Komentářů: 10, poslední včera 17:38
Rozcestník

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

4.2. 16:35 Franta Hanzlík
BFU nemůže změnit práva vlastního souboru - temná magie?!
Přečteno: 563×
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

Řešení dotazu:


Odpovědi

4.2. 18:47 debian+
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
4.2. 19:27 debian+
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
kukal si aj toto?
4.2. 20:52 Franta Hanzlík
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
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 avatar 4.2. 18:48 Pavel 'TIGER' Růžička | skóre: 47
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
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?
4.2. 20:14 Franta Hanzlík
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
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...
4.2. 20:48 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!

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.

4.2. 21:11 Franta Hanzlík
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
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 avatar 4.2. 21:01 Pavel 'TIGER' Růžička | skóre: 47
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
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 avatar 4.2. 21:04 Pavel 'TIGER' Růžička | skóre: 47
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
Případně je překopírovat jinam, původní smazat a z kopie je vrátit na původní místo?
4.2. 22:26 Franta Hanzlík
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
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...
4.2. 22:07 Franta Hanzlík
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
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?
5.2. 07:01 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!

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.

5.2. 09:04 Franta Hanzlík
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
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!
4.2. 19:31 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
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?
4.2. 20:41 Franta Hanzlík
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
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.
4.2. 21:15 PetebLazar
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
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
4.2. 22:20 Franta Hanzlík
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
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)
5.2. 06:56 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
Ale tohle se týká ovelayfs. Nikoliv ext.
5.2. 07:17 PetebLazar
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
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.
5.2. 09:10 Franta Hanzlík
Rozbalit Rozbalit vše Re: BFU nemůže změnit práva vlastního souboru - temná magie?!
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!

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.