[Linux] Nieuwe files hebben geen permissions

[Mastakilla]

code:

ppzg18l@rusipvteur010:/appl/sa-tools/testdir> ls -la
total 36
drwxr-sr-x  2 ppzg18l www_neu   0 Oct  3 10:45 .
drwxr-sr-x 10 root    www_neu 265 Oct  3 10:45 ..

ppzg18l@rusipvteur010:/appl/sa-tools/testdir> touch testfile
touch: setting times of `testfile': Permission denied

ppzg18l@rusipvteur010:/appl/sa-tools/testdir> ls -la
total 38
drwxr-sr-x  2 ppzg18l www_neu  26 Oct  3 10:46 .
drwxr-sr-x 10 root    www_neu 265 Oct  3 10:45 ..
----------  1 ppzg18l www_neu   0 Oct  3 10:46 testfile

ppzg18l@rusipvteur010:/appl/sa-tools/testdir> umask
0027
ppzg18l@rusipvteur010:/appl/sa-tools/testdir> getfacl . testfile 
# file: .
# owner: ppzg18l
# group: www_neu
# flags: -s-
user::rwx
group::r-x
other::r-x

# file: testfile
# owner: ppzg18l
# group: www_neu
user::---
group::---
other::---

ppzg18l@rusipvteur010:/appl/sa-tools/testdir>

Iemand een idee wat er hier aan de hand is? Ik ben owner van de file and parent folder en heb rwx op de parent folder...

Het OS is SLES11SP4

[Hero of Time]

Welk filesystem hebben we het over? Wat zijn de mount opties? Ik zie een sticky bit voor groep, wat zijn de effectieve rechten die erop gezet zijn (welke mask, en niet de uitvoer van getfacl maar ls -l in de bovenliggende map)?

Het is ook wel gek dat de '.' een grootte heeft van 0. Standaard zijn mappen, ook als die leeg zijn, 4096. Maar dat kan dan weer afhankelijk zijn van het file system.

Oh, en heb je hier niet te maken met iets als SELinux oid?

[ Voor 7% gewijzigd door Hero of Time op 03-10-2020 11:00 ]

[Mastakilla]

code:

rusipvteur010:/appl/sa-tools/testdir # mount | grep sa-tools
rusn55isln03.censored.com:/ifs/ovit/jump0000000/data001/oveng/sa-tools on /appl/sa-tools type nfs (rw,addr=10.81.43.44)
rusipvteur010:/appl/sa-tools # cat /etc/fstab | grep sa-tools
rusn55isln03.censored.com:/ifs/ovit/jump0000000/data001/oveng/sa-tools   /appl/sa-tools     nfs defaults    0 0

rusipvteur010:/appl/sa-tools # chmod g-s testdir
rusipvteur010:/appl/sa-tools # su ppzg18l
ppzg18l@rusipvteur010:/appl/sa-tools> cd testdir/
ppzg18l@rusipvteur010:/appl/sa-tools/testdir> touch testfile2
touch: setting times of `testfile2': Permission denied
ppzg18l@rusipvteur010:/appl/sa-tools/testdir> ls -la
total 39
drwxr-xr-x  2 ppzg18l www_neu  53 Oct  3 12:08 .
drwxr-sr-x 10 root    www_neu 265 Oct  3 10:45 ..
----------  1 ppzg18l www_neu   0 Oct  3 10:46 testfile
----------  1 ppzg18l users     0 Oct  3 12:08 testfile2

rusipvteur010:/appl/sa-tools # ls -la
total 145
drwxr-sr-x 10 root    www_neu     265 Oct  3 10:45 .
drwxr-xr-x  8 root    root       4096 Jan 24  2020 ..
drwxr-sr-x  2 ppzg18l www_neu     141 Oct  3 11:54 repo_conf
drwxr-sr-x  2 ppzg18l www_neu      26 Oct  3 10:46 testdir

rusipvteur010:/appl/sa-tools # getenforce
If 'getenforce' is not a typo you can run the following command to lookup the package that contains the binary:
    command-not-found getenforce
-bash: getenforce: command not found
rusipvteur010:/appl/sa-tools # sestatus
If 'sestatus' is not a typo you can run the following command to lookup the package that contains the binary:
    command-not-found sestatus
-bash: sestatus: command not found
rusipvteur010:/appl/sa-tools # selinuxenabled
If 'selinuxenabled' is not a typo you can run the following command to lookup the package that contains the binary:
    command-not-found selinuxenabled
-bash: selinuxenabled: command not found

• Het is een NFS FS
• Als ik de setgid bit afzet, dan worden nieuwe files owned door de groep van de user ppzg18l, nl users, ipv de webserver groep www_neu
• Hoe je de mask ziet van de setgid bit (sticky bit is denk ik niet geset?) weet ik niet zeker. Heb een 'ls -la' van de parent folder gedaan zoals je vroeg...
• SELinux lijkt niet enabled

[ Voor 17% gewijzigd door Mastakilla op 03-10-2020 12:13 ]

[Hero of Time]

Misschien heeft SLES iets anders dan SELinux, zoals AppArmor (dat gebruiken Ubuntu en Debian ook). Iets moet hier de reden van zijn.

Omdat het om een NFS share gaat, kijk eens wat er op de NFS server gebeurt. Bekijk de logs, ook van de client waarop je dit allemaal uitvoert. Er moet ergens een aanwijzing zijn voor de permission denied.

[Mastakilla]

De permission denied zelf lijkt me logisch, niet? Dat is toch omdat de nieuw-aangemaakte file geen permissies heeft (---------- of 0000)?

AppArmor ken ik niet zoveel van eigenlijk, maar hier is de status van de service:

code:

rusipvteur010:~ # service boot.apparmor status
apparmor module is loaded.
17 profiles are loaded.
17 profiles are in enforce mode.
   /bin/ping
   /sbin/klogd
   /sbin/syslog-ng
   /sbin/syslogd
   /usr/lib/PolicyKit/polkit-explicit-grant-helper
   /usr/lib/PolicyKit/polkit-grant-helper
   /usr/lib/PolicyKit/polkit-grant-helper-pam
   /usr/lib/PolicyKit/polkit-read-auth-helper
   /usr/lib/PolicyKit/polkit-resolve-exe-helper
   /usr/lib/PolicyKit/polkit-revoke-helper
   /usr/lib/PolicyKit/polkitd
   /usr/sbin/avahi-daemon
   /usr/sbin/identd
   /usr/sbin/mdnsd
   /usr/sbin/nscd
   /usr/sbin/ntpd
   /usr/sbin/traceroute
0 profiles are in complain mode.
5 processes have profiles defined.
5 processes are in enforce mode :
   /sbin/klogd (2973) 
   /sbin/syslog-ng (2970) 
   /usr/sbin/nscd (3834) 
   /usr/sbin/ntpd (3797) 
   /usr/sbin/ntpd (3795) 
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
rusipvteur010:~ #

Het lijkt maw wel actief...

[Hero of Time]

Mastakilla schreef op zaterdag 3 oktober 2020 @ 13:17:
De permission denied zelf lijkt me logisch, niet? Dat is toch omdat de nieuw-aangemaakte file geen permissies heeft (---------- of 0000)?

En hier denk je dus verkeerdom. De permission denied krijg je niet omdat het bestand geen rechten heeft, het bestand heeft geen rechten omdat het een permission denied kreeg bij het aanmaken ervan. Het aanmaken mislukt dus al en juist daar moet je naar gaan zoeken waarom dat is.

AppArmor ken ik niet zoveel van eigenlijk, maar hier is de status van de service:
...
Het lijkt maw wel actief...

Dat zou mogelijk in de weg kunnen zitten en de foutmelding verklaren. Maar ik ben compleet onbekend met AppArmor om hier iets verder over te kunnen zeggen. Bij m'n RHCSA en RHCE cursussen en examens werd er met SELinux gewerkt en waren er aparte policies voor NFS locaties. Wellicht dat het met AA net zo is.

Zoals eerder gezegd, check de logs. Zowel op je client als de NFS server. Wat is dat voor een bak? Een simpele NAS zoals een Synology of Qnap, of een uitgebreider ding zoals een Linux server of iets als NetApp oid? Ga zoeken. Hier afwachten tot iemand je het magische antwoord geeft heeft geen zin, want we hebben helemaal niets om verder mee te gaan.

[DukeBox]

Als het een NFS mount is dan kan je op mount niveau de default user rechten regelen maar ook op de NFS host deze overrulen. Ik gok dat dit laatste gedaan is maar dan met een UID/GUID die niet op je lokale systeem bekend zijn.

[Mastakilla]

Nogmaals dank voor de support. Ik had intussen opgegeven er nog verder aan te werken in het weekend en heb deze ochtend een collega, met kennis over de NFS, hierover aangesproken.

Wat blijkt, het is inderdaad de NFS die hier moeilijk doet...

De details weet ik niet, maar blijkbaar is de NFS (EMC Isilon) geconfigureerd om goed te werken voor Windows mounts en werkt hij hierdoor erg slecht bij Linux mounts.

De "oplossing / workaround" is om de folder in een bepaalde specifieke locatie aan te maken (waar hij de correcte permissies van de Isilon krijgt) en deze dan te verplaatsen naar waar je hem wilt hebben. Als je folder rechtstreeks maakt waar je hem wilt hebben, dan krijgt hij van de Isilon niet de nodige permissies en doet het blijkbaar allemaal wat raar...

Dat dit "suboptimaal" is lijkt me duidelijk, maar ja, zo is er wel meer en ik zie dit nog niet zo snel een prioriteit worden om het echt op te lossen... Dus ga ik nog even verder met deze rare workaround

[Hero of Time]

Dat is nogal achterlijk hoe het is opgezet. Waarom zou je in vredesnaam je NFS server inrichten om met het idiote Windows systeem te werken? Die wordt veel blijer van SMB. Dus geen wonder dat het zo slecht werkt. Er wordt gevraagd om een netwerk file system aan te bieden aan een OS dat het niet 100% geïmplementeerd heeft, waardoor je dus quirks moet gaan toepassen om dat te laten werken. En als dan een client komt dat wel NFS fatsoenlijk ondersteund, heb je fecaliën aan een rond, over 't algemeen glazen, object.

Sterkte met dit zooitje.

[Mastakilla]

Bedankt, sterkte kan ik, zoals je ziet, soms wel gebruiken ja

In een grote omgeving heb je jammergenoeg wel eens wat legacy-crap, waar je niet makkelijk vanaf geraakt... Zoals het antieke SLES11, oude Isilons (NFSv3) die dan nog voor shares Windows gebruikt worden (misschien ondersteunen die dingen zelfs geen SMB? Maar dat is niet mijn winkel...)
We hebben zelfs nog Solaris 8 / RHEL5 enzo

[ Voor 4% gewijzigd door Mastakilla op 05-10-2020 15:38 ]