Bagikan melalui

Memahami daftar kontrol akses NFSv4.x di Azure NetApp Files

Protokol NFSv4.x dapat menyediakan kontrol akses dalam bentuk daftar kontrol akses (ACL), yang secara konseptual mirip dengan ACL yang digunakan dalam SMB melalui izin Windows NTFS. NFSv4.x ACL terdiri dari Entri Kontrol Akses (ACE) individual, yang masing-masing menyediakan direktif kontrol akses ke server.

Diagram entitas kontrol akses ke Azure NetApp Files.

Setiap NFSv4.x ACL dibuat dengan format type:flags:principal:permissions.

  • Jenis – jenis ACL yang didefinisikan. Pilihan yang valid termasuk Access (A), Deny (D), Audit (U), Alarm (L). Azure NetApp Files mendukung jenis ACL Akses, Tolak, dan Audit, tetapi ACL Audit, meskipun dapat diatur, saat ini tidak menghasilkan log audit.
  • Bendera – menambahkan konteks tambahan untuk ACL. Ada tiga jenis bendera ACE: grup, warisan, dan administratif. Untuk informasi selengkapnya tentang bendera, lihat flag NFSv4.x ACE.
  • Utama – mendefinisikan pengguna atau grup yang sedang ditetapkan ACL. Prinsipal pada NFSv4.x ACL menggunakan format name@ID-DOMAIN-STRING.COM. Untuk informasi selengkapnya tentang prinsipal, lihat prinsipal pengguna dan grup NFSv4.x.
  • Izin – di mana tingkat akses untuk prinsipal didefinisikan. Setiap izin ditetapkan satu huruf (misalnya, baca mendapatkan "r", tulis mendapat "w" dan sebagainya). Akses penuh akan menggabungkan setiap surat izin yang tersedia. Untuk informasi selengkapnya, lihat Izin NFSv4.x.

A:g:group1@contoso.com:rwatTnNcCy adalah contoh ACL yang valid, mengikuti type:flags:principal:permissions format . Contoh ACL memberikan akses penuh ke grup group1 di domain ID contoso.com.

Penanda NFSv4.x ACE

Penanda ACE membantu memberikan informasi lebih banyak mengenai ACE dalam ACL. Misalnya, jika ACE grup ditambahkan ke ACL, bendera grup perlu digunakan untuk menunjuk prinsipal adalah grup dan bukan pengguna. Dimungkinkan di lingkungan Linux untuk memiliki pengguna dan nama grup yang identik, sehingga bendera memastikan ACE dihormati, maka server NFS perlu mengetahui jenis prinsipal apa yang sedang ditentukan.

Penanda lain dapat digunakan untuk mengontrol ACE, seperti pewarisan dan penanda administratif.

Akses dan tolak bendera

Tanda akses (A) dan tolak (D) digunakan untuk mengontrol jenis ACE keamanan. ACE mengontrol tingkat izin akses pada file atau folder untuk pengguna. ACE penolakan secara eksplisit melarang prinsipal mengakses file atau folder, bahkan jika ada ACE akses yang ditetapkan yang memungkinkan prinsipal tersebut mengakses objek. Tolak ACE selalu mengesampingkan ACE akses. Secara umum, hindari menggunakan ACL tolak, karena ACL NFSv4.x mengikuti model "penolakan default", yang berarti jika ACL tidak ditambahkan, maka tolak adalah implisit. ACE penolakan dapat membuat komplikasi yang tidak perlu dalam manajemen ACL.

Tanda pewarisan

Penanda pewarisan mengontrol bagaimana ACL berperilaku pada file yang dibuat di bawah direktori induk dengan penanda pewarisan diaktifkan. Ketika bendera pewarisan diatur, file dan/atau direktori mewarisi ACL dari folder induk. Atribut pewarisan hanya dapat diterapkan ke direktori, jadi ketika subdirektori dibuat, subdirektori tersebut mewarisi atribut tersebut. File yang dibuat di bawah direktori induk dengan bendera turunan akan mewarisi ACL, tetapi tidak mewarisi bendera turunan.

Tabel berikut ini menjelaskan bendera pewarisan yang tersedia dan perilakunya.

Bendera pewarisan Perilaku
d - Direktori di bawah direktori induk mewarisi ACL
- Bendera warisan juga diwariskan
f - File di bawah direktori induk mewarisi ACL
- File tidak mengatur bendera pewarisan
saya Hanya untuk pewarisan; ACL tidak berlaku untuk direktori saat ini, tetapi pewarisan harus diterapkan pada objek-objek yang berada di bawah direktori tersebut.
n - Tidak ada penyebaran warisan
Setelah ACL diwariskan, tanda warisan dihapus pada objek di bawah parent

Contoh Daftar Kontrol Akses NFSv4.x

Dalam contoh berikut, ada tiga ACE yang berbeda dengan bendera warisan yang berbeda:

  • hanya mewarisi direktori (di)
  • hanya mewarisi file (fi)
  • baik file maupun direktori mewarisi (fdi)
# nfs4_getfacl acl-dir

# file: acl-dir/
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdi:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

User1 memiliki direktori yang hanya mewarisi ACL. Pada subdirektori yang dibuat di bawah induk, ACL diwariskan, tetapi pada file di bawah induk, tidak.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file 
                       << ACL missing
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

User2 memiliki bendera pewarisan file dan direktori. Akibatnya, file dan direktori di bawah direktori dengan entri ACE tersebut mewarisi ACL, tetapi file tidak akan mewarisi bendera.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy << no flag
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

User3 hanya memiliki bendera pewarisan file. Akibatnya, hanya file di bawah direktori dengan entri ACE yang mewarisi ACL, tetapi tidak mewarisi bendera karena hanya dapat diterapkan ke ACL direktori.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy << no flag
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

Ketika bendera "no-propagate" (n) diatur pada ACL, bendera dihapus pada pembuatan direktori berikutnya di bawah induk. Dalam contoh berikut, user2 memiliki bendera n yang diatur. Akibatnya, subdirektori menghapus bendera warisan untuk prinsipal dan objek yang dibuat di bawah subdirektori tersebut tidak mewarisi ACE dari user2.

#  nfs4_getfacl /mnt/acl-dir

# file: /mnt/acl-dir
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdn:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

#  nfs4_getfacl inherit-dir/

# file: inherit-dir/
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A::user2@CONTOSO.COM:rwaDxtTnNcCy << flag cleared
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# mkdir subdir
# nfs4_getfacl subdir

# file: subdir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
<< ACL not inherited
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

Mewarisi bendera adalah cara untuk mengelola ACL NFSv4.x Anda dengan lebih mudah, hemat Anda dari pengaturan ACL secara eksplisit setiap kali Anda membutuhkannya.

Bendera administratif

Bendera administratif di ACL NFSv4.x adalah bendera khusus yang hanya digunakan dengan jenis Audit dan Alarm ACL. Bendera ini menentukan keberhasilan (S) atau kegagalan (F) dalam upaya akses untuk tindakan yang akan dilakukan.

Audit ACL ini adalah contohnya, di mana user1 diaudit untuk upaya akses yang gagal pada setiap kelas izin: U:F:user1@contoso.com:rwatTnNcCy.

Azure NetApp Files hanya mendukung pengaturan penanda administratif untuk ACE Audit, namun ACE tidak berfungsi. Alarm ACE tidak didukung di Azure NetApp Files.

Pengguna dan anggota grup NFSv4.x

Dengan ACL NFSv4.x, prinsipal pengguna dan grup menentukan objek tertentu yang harus diterapkan ACE. Kepala Sekolah umumnya mengikuti format name@ID-DOMAIN-STRING.COM. Bagian "nama" dari entitas utama dapat menjadi pengguna atau grup, tetapi pengguna atau grup tersebut harus dapat diidentifikasi di Azure NetApp Files dengan koneksi server LDAP saat menetapkan domain ID NFSv4.x. Jika name@domain tidak dapat diselesaikan oleh Azure NetApp Files, maka operasi ACL gagal dengan kesalahan "argumen yang tidak valid".

# nfs4_setfacl -a A::noexist@CONTOSO.COM:rwaxtTnNcCy inherit-file
Failed setxattr operation: Invalid argument

Anda dapat memeriksa dalam Azure NetApp Files apakah nama dapat diselesaikan menggunakan daftar ID grup LDAP. Arahkan ke Dukungan + Pemecahan Masalah lalu Daftar ID Grup LDAP.

Akses pengguna dan grup lokal melalui NFSv4.x ACL

Pengguna dan grup lokal juga dapat digunakan pada NFSv4.x ACL jika hanya ID numerik yang ditentukan dalam ACL. Nama pengguna atau ID numerik dengan ID domain yang sudah ditentukan tidak berhasil.

Contohnya:

# nfs4_setfacl -a A:fdg:3003:rwaxtTnNcCy NFSACL
# nfs4_getfacl NFSACL/
A:fdg:3003:rwaxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rwaDxtTnNcy
A::EVERYONE@:rwaDxtTnNcy

# nfs4_setfacl -a A:fdg:3003@CONTOSO.COM:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

# nfs4_setfacl -a A:fdg:users:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

Saat pengguna lokal atau grup ACL diatur, pengguna atau grup apa pun yang sesuai dengan ID numerik pada ACL menerima akses ke objek. Untuk ACL grup lokal, pengguna meneruskan keanggotaan grupnya ke Azure NetApp Files. Jika ID numerik grup dengan akses ke file melalui permintaan pengguna ditampilkan ke server NFS Azure NetApp Files, maka akses diizinkan sesuai ACL.

Kredensial yang diteruskan dari klien ke server dapat dilihat melalui pengambilan paket seperti yang terlihat di bawah ini.

Gambar yang menggambarkan sampel pengambilan paket dengan kredensial.

Catatan Penting:

  • Menggunakan pengguna dan grup lokal untuk ACL berarti bahwa setiap klien yang mengakses file/folder harus memiliki ID pengguna dan grup yang cocok.
  • Saat menggunakan ID numerik untuk ACL, Azure NetApp Files secara implisit mempercayai bahwa permintaan masuk valid dan bahwa pengguna yang meminta akses adalah siapa yang mereka katakan dan merupakan anggota grup yang mereka klaim sebagai anggotanya. Numerik pengguna atau grup dapat dipalsukan jika penyerang mengetahui ID numerik dan dapat mengakses jaringan menggunakan klien dengan kemampuan membuat pengguna dan grup secara lokal.
  • Jika pengguna adalah anggota lebih dari 16 grup, maka grup apa pun setelah grup keenam belas (dalam urutan alfanumerik) ditolak akses ke file atau folder, kecuali LDAP dan dukungan grup yang diperluas digunakan.
  • LDAP dan string nama name@domain penuh sangat disarankan saat menggunakan ACL NFSv4.x untuk pengelolaan dan keamanan yang lebih baik. Repositori pengguna dan grup yang dikelola secara terpusat lebih mudah dipertahankan dan lebih sulit untuk di-spoof, sehingga membuat akses pengguna yang tidak diinginkan lebih kecil kemungkinannya.

Domain NFSv4.x ID

Domain ID adalah komponen penting dari prinsipal, di mana domain ID harus cocok baik di klien maupun dalam Azure NetApp Files agar nama pengguna dan grup, terutama root, terlihat dengan benar pada kepemilikan file/folder.

Azure NetApp Files mendefault domain ID NFSv4.x sebagai pengaturan domain DNS untuk volume tersebut. Klien-klien NFS secara default menggunakan domain DNS untuk domain ID NFSv4.x. Jika domain DNS klien berbeda dari domain DNS Azure NetApp Files, maka ketidakcocokan terjadi. Saat mencantumkan izin file dengan perintah seperti ls, pengguna/grup muncul sebagai "tidak ada".

Ketika ketidakcocokan domain terjadi antara klien NFS dan Azure NetApp Files, periksa log klien untuk kesalahan yang mirip dengan:

August 19 13:14:29 nfsidmap[17481]: nss_getpwnam: name 'root@microsoft.com' does not map into domain ‘CONTOSO.COM'

ID domain klien NFS dapat digantikan menggunakan pengaturan "Domain" pada file /etc/idmapd.conf. Misalnya: Domain = CONTOSO.COM.

Azure NetApp Files juga memungkinkan Anda mengubah domain ID NFSv4.1. Untuk detail tambahan, lihat Cara: Konfigurasi Domain ID NFSv4.1 untuk Azure NetApp Files.

Izin NFSv4.x

Izin NFSv4.x adalah cara untuk mengontrol tingkat akses pengguna atau perwakilan grup tertentu pada file atau folder. Izin di NFSv3 hanya mengizinkan tingkat definisi akses baca/tulis/jalankan (rwx), tetapi NFSv4.x menyediakan serangkaian kontrol akses yang lebih terperinci sebagai peningkatan atas bit mode NFSv3.

Ada 13 izin yang dapat diatur untuk pengguna, dan 14 izin yang dapat diatur untuk grup.

Surat izin Izin diberikan
r Membaca file dan folder data atau daftar
w Menulis data/membuat file dan folder
sebuah Menambahkan data/membuat subdirektori
x Menjalankan file/menelusuri direktori
d Hapus file/direktori
D Hapus subdirektori (hanya direktori)
t Baca atribut (GETATTR)
T Menulis atribut (SETATTR/chmod)
n Baca atribut yang dinamai
N Menulis atribut bernama
c Membaca ACL
C Tulis ACL
o Ubah pemilik (chown)
y Masukan/Keluaran Sinkron

Saat izin akses diatur, pengguna atau prinsipal grup mematuhi hak yang ditetapkan tersebut.

Contoh izin NFSv4.x

Contoh berikut menunjukkan cara kerja izin yang berbeda dengan skenario konfigurasi yang berbeda.

Pengguna dengan akses hanya baca (r saja)

Dengan akses baca-saja, pengguna dapat membaca atribut dan data, tetapi akses tulis apa pun (data, atribut, pemilik) ditolak.

A::user1@CONTOSO.COM:r

sh-4.2$ ls -la
total 12
drwxr-xr-x 3 root root 4096 Jul 12 12:41 .
drwxr-xr-x 3 root root 4096 Jul 12 12:09 ..
-rw-r--r-- 1 root root    0 Jul 12 12:41 file
drwxr-xr-x 2 root root 4096 Jul 12 12:31 subdir
sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ chown user1 file
chown: changing ownership of ‘file’: Operation not permitted
sh-4.2$ nfs4_setfacl -e /mnt/acl-dir/inherit-dir
Failed setxattr operation: Permission denied
sh-4.2$ rm file
rm: remove write-protected regular empty file ‘file’? y
rm: can't remove ‘file’: Permission denied
sh-4.2$ cat file
Test text

Pengguna dengan akses baca (r) dan atribut tulis (T)

Dalam contoh ini, izin pada file dapat diubah karena izin atribut tulis (T), tetapi tidak ada file yang dapat dibuat karena hanya akses baca yang diizinkan. Konfigurasi ini menggambarkan jenis kontrol terperinci yang dapat disediakan NFSv4.x ACL.

A::user1@CONTOSO.COM:rT

sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:23 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
-rw-r--r--  1 root     root      10 Jul 12 16:22 file
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rw-r--r--  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ chmod 777 user1-file
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:41 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rwxrwxrwx  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ rm user1-file
rm: can't remove ‘user1-file’: Permission denied

Menerjemahkan bit mode ke dalam izin Daftar Kontrol Akses (ACL) NFSv4.x

Ketika chmod dijalankan pada objek yang memiliki NFSv4.x ACL yang ditetapkan, serangkaian ACL sistem diperbarui dengan izin baru. Misalnya, jika izin diatur ke 755, maka file ACL sistem akan diperbarui. Tabel berikut menunjukkan cara setiap nilai numerik pada bit mode diterjemahkan menjadi izin pada ACL NFSv4.

Lihat Izin NFSv4.x untuk tabel yang menguraikan semua izin.

Mode bit numerik Izin yang sesuai untuk NFSv4.x
1 – eksekusi (x) Jalankan, baca atribut, baca ACL, sinkronkan I/O (xtcy)
2 – tulis (w) Menulis, menambahkan data, membaca atribut, menulis atribut, menulis atribut bernama, membaca ACL, menyinkronkan I/O (watTNcy)
3 – tulis/jalankan (wx) Menulis, menambahkan data, menjalankan, membaca atribut, menulis atribut, menulis atribut bernama, membaca ACL, menyinkronkan I/O (waxtTNcy)
4 – baca (r) Membaca, membaca atribut, membaca atribut bernama, membaca ACL, menyinkronkan I/O (rtncy)
5 – baca/jalankan (rx) Membaca, menjalankan, membaca atribut, membaca atribut bernama, membaca ACL, menyinkronkan I/O (rxtncy)
6 – Baca/Tulis (rw) Membaca, menulis, menambahkan data, membaca atribut, menulis atribut, membaca atribut bernama, menulis atribut bernama, membaca ACL, menyinkronkan I/O (rwatTnNcy)
7 – baca/tulis/jalankan (rwx) Kontrol penuh/semua izin

Cara kerja ACL NFSv4.x dengan Azure NetApp Files

Azure NetApp Files mendukung ACL NFSv4.x secara asli ketika volume mengaktifkan NFSv4.1 untuk akses. Tidak ada yang dapat diaktifkan pada volume untuk dukungan ACL, tetapi agar ACL NFSv4.1 berfungsi paling baik, server LDAP dengan pengguna dan grup UNIX diperlukan untuk memastikan bahwa Azure NetApp Files dapat menyelesaikan prinsipal yang diatur pada ACL dengan aman. Pengguna lokal dapat digunakan dengan ACL NFSv4.x, tetapi mereka tidak memberikan tingkat keamanan yang sama dengan ACL yang digunakan dengan server LDAP.

Ada pertimbangan yang perlu diingat dengan fungsionalitas ACL di Azure NetApp Files.

Warisan Daftar Kontrol Akses (ACL)

Di Azure NetApp Files, bendera pewarisan ACL dapat digunakan untuk menyederhanakan manajemen ACL dengan ACL NFSv4.x. Ketika bendera pewarisan diatur, ACL pada direktori induk dapat menyebar ke subdirektori dan file tanpa interaksi lebih lanjut. Azure NetApp Files menerapkan perilaku warisan ACL standar sesuai RFC-7530.

Tolak ACE

Tolak ACE di Azure NetApp Files digunakan untuk secara eksplisit membatasi pengguna atau grup mengakses file atau folder. Subset izin dapat didefinisikan untuk memberikan kontrol terperinci atas ACE tolak. Ini beroperasi dalam metode standar yang disebutkan dalam RFC-7530.

Pelestarian Ligamen Cruciatum Anterior (ACL)

Ketika chmod dilakukan pada file atau folder di Azure NetApp Files, semua ACE yang ada dipertahankan pada ACL selain ACL sistem (OWNER@, GROUP@, EVERYONE@). Izin ACE tersebut dimodifikasi sebagaimana didefinisikan oleh bit mode numerik yang ditentukan oleh perintah chmod. Hanya ACE yang dimodifikasi atau dihapus secara manual melalui perintah nfs4_setfacl yang dapat diubah.

Perilaku NFSv4.x ACL di lingkungan protokol ganda

Protokol ganda mengacu pada penggunaan SMB dan NFS pada volume Azure NetApp Files yang sama. Kontrol akses protokol ganda ditentukan dengan gaya keamanan yang digunakan volume, tetapi pemetaan nama pengguna memastikan bahwa pengguna Windows dan pengguna UNIX yang berhasil memetakan satu sama lain memiliki izin akses yang sama ke data.

Ketika ACL NFSv4.x digunakan pada volume gaya keamanan UNIX, perilaku berikut dapat diamati saat menggunakan volume protokol ganda dan mengakses data dari klien SMB.

  • Nama pengguna Windows perlu dipetakan dengan benar ke nama pengguna UNIX untuk resolusi kontrol akses yang tepat.
  • Dalam volume gaya keamanan UNIX (di mana NFSv4.x ACL akan diterapkan), jika tidak ada pengguna UNIX yang valid di server LDAP untuk memetakan pengguna Windows, maka pengguna UNIX default yang disebut pcuser (dengan uid numerik 65534) akan digunakan untuk pemetaan.
  • File yang ditulis oleh pengguna Windows tanpa pemetaan pengguna UNIX yang valid ditampilkan sebagai dimiliki oleh ID numerik 65534, yang sesuai dengan nama pengguna "nfsnobody" atau "nobody" di klien Linux dari pemasangan NFS mount. Ini berbeda dari ID numerik 99 yang biasanya terlihat pada masalah ID domain NFSv4.x. Untuk memverifikasi ID numerik yang digunakan, gunakan ls -lan perintah .
  • File dengan pemilik yang salah tidak memberikan hasil yang diharapkan dari bit mode UNIX atau dari ACL NFSv4.x.
  • ACL NFSv4.x dikelola dari klien NFS. Klien SMB tidak dapat melihat atau mengelola ACL NFSv4.x.

Dampak Umask pada ACL NFSv4.x

ACL NFSv4 menyediakan kemampuan untuk menawarkan warisan ACL. Pewarisan ACL berarti bahwa file atau folder yang dibuat di bawah objek yang memiliki set ACL NFSv4 dapat mewarisi ACL berdasarkan konfigurasi bendera pewarisan pengaturan ACL.

Umask digunakan untuk mengontrol tingkat izin tempat file dan folder dibuat dalam direktori. Secara default, Azure NetApp Files memungkinkan umask untuk mengganti ACL yang diwariskan, yang merupakan perilaku yang diharapkan sesuai dengan RFC-7530.

Untuk informasi selengkapnya, lihat umask.

Cara Kerja Chmod/chown dengan NFSv4.x ACL

Di Azure NetApp Files, Anda dapat menggunakan perintah ubah kepemilikan (chown) dan ubah bit mode (chmod) untuk mengelola izin file dan direktori pada NFSv3 dan NFSv4.x.

Saat menggunakan ACL NFSv4.x, kontrol yang lebih terperinci diterapkan ke file dan folder mengurangi kebutuhan akan perintah chmod. Chown masih memiliki tempat, karena NFSv4.x ACL tidak menetapkan kepemilikan.

Ketika chmod dijalankan di Azure NetApp Files pada file dan folder dengan NFSv4.x ACL diterapkan, bit mode diubah pada objek. Selain itu, serangkaian ACEs sistem dimodifikasi untuk mencerminkan bit-bit mode tersebut. Jika ASE sistem dihapus, bit mode akan dibersihkan. Contoh dan deskripsi yang lebih lengkap dapat ditemukan di bagian tentang ACE sistem di bawah ini.

Saat chown dijalankan di Azure NetApp Files, pemilik yang ditetapkan dapat dimodifikasi. Kepemilikan file tidak terlalu penting saat menggunakan ACL NFSv4.x seperti saat menggunakan bit mode, karena ACL dapat digunakan untuk mengontrol izin dengan cara yang tidak dapat dilakukan oleh konsep pemilik/grup/semua orang dasar. Chown di Azure NetApp Files hanya dapat dijalankan sebagai root (baik sebagai root atau dengan menggunakan sudo), karena kontrol ekspor dikonfigurasi untuk hanya memungkinkan root untuk membuat perubahan kepemilikan. Karena ini dikendalikan oleh aturan kebijakan ekspor default di Azure NetApp Files, entri NFSv4.x ACL yang memungkinkan modifikasi kepemilikan tidak berlaku.

# su user1
# chown user1 testdir
chown: changing ownership of ‘testdir’: Operation not permitted
# sudo chown user1 testdir
# ls -la | grep testdir
-rw-r--r--  1 user1    root     0 Jul 12 16:23 testdir

Aturan kebijakan ekspor pada volume dapat dimodifikasi untuk mengubah perilaku ini. Di menu Kebijakan Ekspor untuk volume, ubah Chown Mode menjadi "tidak terbatas."

Cuplikan layar menu kebijakan ekspor mengubah mode chown menjadi tidak dibatasi.

Setelah dimodifikasi, kepemilikan dapat diubah oleh pengguna selain root jika mereka memiliki hak akses yang sesuai. Ini memerlukan izin "Ambil Kepemilikan" NFSv4.x ACL (ditunjuk oleh huruf "o"). Kepemilikan juga dapat diubah jika pengguna yang mengubah kepemilikan saat ini memiliki file atau folder.

A::user1@contoso.com:rwatTnNcCy  << no ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
chown: changing ownership of 'newfile3': Permission denied

A::user1@contoso.com:rwatTnNcCoy  << with ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
user1@ubuntu:/mnt/testdir$ ls -la
total 8
drwxrwxrwx 2 user2 root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root  root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1 root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root  root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 user1 4294967294    0 Jul 14 16:31 newfile3

Sistem ACE

Pada setiap ACL, ada serangkaian ACE sistem: OWNER@, GROUP@, EVERYONE@. Contohnya:

A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

ACE ini sesuai dengan izin bit mode klasik yang biasanya Anda temui di NFSv3 dan berhubungan langsung dengan izin tersebut. Ketika chmod dijalankan pada objek, ACL sistem ini berubah untuk mencerminkan izin tersebut.

# nfs4_getfacl user1-file

# file: user1-file
A::user1@CONTOSO.COM:rT
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

# chmod 755 user1-file

# nfs4_getfacl user1-file

# file: user1-file
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rxtncy

Jika ASE sistem tersebut dihapus, maka tampilan izin berubah sehingga bit mode normal (rwx) muncul sebagai tanda hubung.

# nfs4_setfacl -x A::OWNER@:rwaxtTnNcCy user1-file
# nfs4_setfacl -x A:g:GROUP@:rxtncy user1-file
# nfs4_setfacl -x A::EVERYONE@:rxtncy user1-file
# ls -la | grep user1-file
----------  1 user1 group1     0 Jul 12 16:23 user1-file

Menghapus ACE sistem adalah cara untuk lebih mengamankan file dan folder, karena hanya pengguna dan prinsipal grup pada ACL (dan root) yang dapat mengakses objek. Menghapus ACE sistem dapat merusak aplikasi yang mengandalkan pandangan mode bit dalam menjalankan fungsionalitas.

Perilaku pengguna root dengan ACL NFSv4.x

Akses root dengan ACL NFSv4.x tidak dapat dibatasi kecuali root di-nonaktifkan. Root squashing adalah proses di mana aturan kebijakan ekspor dikonfigurasi sehingga root dipetakan ke pengguna anonim untuk membatasi akses. Akses root dapat dikonfigurasi dari menu kebijakan Ekspor volume dengan mengubah aturan kebijakan Akses root menjadi nonaktif.

Untuk mengkonfigurasi root squashing, arahkan ke menu Export policy pada volume lalu ubah opsi "Akses root" menjadi "mati" untuk aturan kebijakan.

Cuplikan layar menu kebijakan ekspor dengan akses root nonaktif.

Efek dari menonaktifkan akses root dan penghapusan root ke pengguna anonim nfsnobody:65534. Akses root kemudian tidak dapat mengubah kepemilikan.

root@ubuntu:/mnt/testdir# touch newfile3
root@ubuntu:/mnt/testdir# ls -la
total 8
drwxrwxrwx 2 user2  root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root   root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1  root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root   root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 nobody 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# ls -lan
total 8
drwxrwxrwx 2  1002          0 4096 Jul 14 16:31 .
drwxrwxrwx 5     0          0 4096 Jul 13 13:46 ..
-rw-r--r-- 1  1001          0    0 Jul 14 15:45 newfile
-rw-r--r-- 1     0          0    0 Jul 14 15:52 newfile2
-rw-r--r-- 1 65534 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# chown root newfile3
chown: changing ownership of 'newfile3': Operation not permitted

Atau, di lingkungan protokol ganda, ACL NTFS dapat digunakan untuk membatasi akses root secara terperinci.

Langkah berikutnya