Umask / PAM / izinlerin tam kontrolünü nasıl alabilirim?


11

// 8 Şubat Güncellendi - Kısaca olağanüstü sorunlar:

  • Dizinler dosyalardan farklı şekilde nasıl umasklanır?
  • Nautilus kopyala / yapıştır üzerine nasıl umask yapılır?
  • SSHFS için umask nasıl ayarlanır?

DURUMUMUZ

Şirketimizden birkaç kişi bir sunucuda oturum açar ve dosya yükler. Hepsinin aynı dosyaları yükleyebilmesi ve üzerine yazabilmesi gerekir. Farklı kullanıcı adlarına sahiptirler, ancak hepsi aynı grubun parçasıdır. Ancak, bu bir internet sunucusudur, bu nedenle "diğer" kullanıcılar (genel olarak) salt okunur erişime sahip olmalıdır. Sahip olmak istediğim şu standart izinler:

dosyalar: 664
dizinler: 771

Amacım, tüm kullanıcıların izinler konusunda endişelenmesine gerek olmamasıdır. Sunucu, bu izinler yeni oluşturulan, kopyalanan veya üzerine yazılan tüm dosya ve dizinlere uygulanacak şekilde yapılandırılmalıdır. Yalnızca bazı özel izinlere ihtiyacımız olduğunda bunu manuel olarak değiştirirdik.

Dosyaları sunucuya Nautilus'ta SFTP-ing ile, sunucuyu sshfs kullanarak monte edip Nautilus'ta yerel bir klasör gibi erişerek ve komut satırında SCP-ing ile yüklüyoruz. Bu temelde durumumuzu ve ne yapmayı amaçladığımızı kapsar.

Şimdi, güzel umask işlevselliği hakkında birçok şey okudum. Anladığım kadarıyla umask (PAM ile birlikte) tam olarak istediğimi yapmama izin vermeli : yeni dosyalar ve dizinler için standart izinler ayarlayın. Ancak, saatler süren okuma ve deneme yanılma işlemlerinden sonra, hala işe yaramıyorum. Birçok beklenmedik sonuç elde ediyorum. Gerçekten sağlam bir umask tutmayı ve cevapsız birçok sorum var. Bulgularım ve bu sorulara yol açan duruşmalarımın bir açıklaması ile birlikte bu soruları aşağıda göndereceğim. Birçok şeyin yanlış gittiği düşünüldüğünde, birkaç şeyi yanlış yaptığımı düşünüyorum. Bu nedenle, birçok soru var.

NOT: Ubuntu 9.10 kullanıyorum ve bu nedenle SFTP sunucusu için umask ayarlamak için sshd_config değiştiremezsiniz . Kurulu SSH OpenSSH_5.1p1 Debian-6ubuntu2 <gerekli OpenSSH 5.4p1. İşte sorular.

1. ETKİ ALACAK PAM DEĞİŞİKLİKLERİ İÇİN YENİDEN BAŞLATILMAM GEREKİR Mİ?

Bununla başlayalım. Çok fazla dosya vardı ve bir şeyleri neyin etkilediğini ve neyin etkilemediğini anlayamadım, çünkü PAM değişikliklerinin etkili olması için tüm sistemi yeniden başlatmam gerekip gerekmediğini de bilmiyordum. Beklenen sonuçları göremedikten sonra yaptım, ama bu gerçekten gerekli mi? Yoksa sunucudan çıkış yapıp tekrar giriş yapabilir miyim ve yeni PAM ilkeleri etkili olmalı mı? Yoksa yeniden yüklemek için bazı 'PAM' programı var mı?

2. TÜM KULLANICILARI TÜM OTURUMLARA ETKİLEYEN TEK BİR DOSYA VAR MI?

Bu yüzden MANY dosyalarını değiştirdim, çünkü MANY farklı şeyler okudum. Aşağıdaki dosyalarda umask ayarını bitirdim:

~/.profile -> umask=0002
~/.bashrc -> umask=0002
/etc/profile -> umask=0002
/etc/pam.d/common-session -> umask=0002
/etc/pam.d/sshd -> umask=0002
/etc/pam.d/login -> umask=0002

Bu değişikliğin tüm kullanıcılar için geçerli olmasını istiyorum, bu nedenle sistem genelinde bir çeşit değişiklik en iyisi olacaktır. Ulaşılabilir mi?

3. TÜMÜNDEN SONRA BU UMASK ŞEYİ ÇALIŞIYOR MU?

Bu yüzden umask'ı mümkün olan her yerde 0002'ye değiştirdikten sonra testler yapıyorum.

------------ SCP -----------

TEST 1:

scp testfile (which has 777 permissions for testing purposes) server:/home/
testfile                                      100%    4     0.0KB/s   00:00   

İzinleri kontrol edelim:

user@server:/home$ ls -l
total 4
-rwx--x--x 1 user uploaders 4 2011-02-05 17:59 testfile (711)

GÜNCELLEME: SADECE pam.d / ortak oturumlarda umask ayarı yapılarak düzeltildi (yorumlara bakın)

--------- SSH ------------

TEST 2:

ssh server
user@server:/home$ touch anotherfile
user@server:/home$ ls -l
total 4
-rw-rw-r-- 1 user uploaders 0 2011-02-05 18:03 anotherfile (664)

-------- SFTP -----------

Nautilus: sftp: // sunucu / ev /

Yeni dosyayı istemciden sunucuya kopyalayıp yapıştırın (istemcide 777)

TEST 3:

user@server:/home$ ls -l
total 4
-rwxrwxrwx 1 user uploaders 3 2011-02-05 18:05 newfile (777)

Nautilus ile yeni bir dosya oluşturun. Terminaldeki dosya izinlerini kontrol edin:

TEST 4:

user@server:/home$ ls -l
total 4
-rw------- 1 user uploaders    0 2011-02-05 18:06 newfile (600)

Demek istediğim ... Burada ne oldu ?! Biz gereken 644 her zaman olsun. Bunun yerine 711, 777, 600 ve sonra bir kez 644 alıyorum. Ve 644, yalnızca en az olası senaryo olan SSH aracılığıyla yeni, boş bir dosya oluştururken elde edilir.

Bu yüzden soruyorum, umask / pam sonuçta işe yarıyor mu?

GÜNCELLEME: SADECE pam.d / ortak oturumlarda umask ayarlayarak test 4 düzeltildi (yorumlara bakın)

4. Peki UMASK SSHFS'YE NE DEMEKTİR?

Bazen sshfs kullanarak yerel olarak bir sunucu bağlarız. Çok kullanışlı. Ama yine de, izin sorunlarımız var.

İşte böyle monte ediyoruz:

sshfs -o idmap=user -o umask=0113 user@server:/home/ /mnt

NOT: umask = 113 kullanıyoruz çünkü sshfs 666 yerine 777'den başlıyor, bu yüzden 113 ile 664 istenen dosya izni olan 664'ü alıyoruz.

Ama şimdi olan şey, tüm dosyaları ve dizinleri 664 gibi görüyoruz . Nautilus'ta / mnt'ye göz atıyoruz ve:

  • Sağ tıklayın -> Yeni Dosya (newfile) --- TEST 5
  • Sağ tıklayın -> Yeni Klasör (yeni klasör) - TEST 6
  • Yerel istemcimizden 777 dosyasını kopyalayıp yapıştırın --- TEST 7

Şimdi komut satırını kontrol edelim:

user@client:/mnt$ ls -l
total 8
-rw-rw-r-- 1 user 1007    3 Feb  5 18:05 copyfile (664)
-rw-rw-r-- 1 user 1007    0 Feb  5 18:15 newfile (664)
drw-rw-r-- 1 user 1007 4096 Feb  5 18:15 newfolder (664)

Ama hey, sunucu tarafında aynı klasörü kontrol edelim:

user@server:/home$ ls -l
total 8
-rwxrwxrwx 1 user uploaders    3 2011-02-05 18:05 copyfile (777)
-rw------- 1 user uploaders    0 2011-02-05 18:15 newfile (600)
drwx--x--x 2 user uploaders 4096 2011-02-05 18:15 newfolder (711)

Ne?! REAL dosya izinleri Nautilus'ta gördüklerimizden çok farklı. Yani sshfs'deki bu umask sadece gerçek olmayan dosya izinlerini gösteren bir 'filtre' oluşturuyor mu? Ve başka bir kullanıcıdan ama gerçek 600 izinleri ancak 644 'sahte' izinleri olan aynı gruptan bir dosya açmaya çalıştım ve ben hala bunu okuyamadı, bu yüzden bu filtre ne iyi ??

5. UMASK TÜM DOSYALAR HAKKINDA. ANCAK DİREKTÖRLER HAKKINDA NELER VAR?

Testlerimden, uygulanan umask'ın bir şekilde dizin izinlerini de etkilediğini görebiliyorum. Ancak, dosyalarımın 664 (002) ve dizinlerimin 771 (006) olmasını istiyorum. Dizinler için farklı bir umask olması mümkün mü?

6. PERHAPS UMASK / PAM GERÇEKTEN SOĞUTMAK, AMA UBUNTU SADECE BUGGY mi?

Bir yandan PAM / UMASK ve Ubuntu ile başarılı olan insanların konularını okudum. Öte yandan, Ubuntu'da umask / PAM / sigorta ile ilgili birçok eski ve daha yeni hata buldum:

Artık neye inanacağımı bilmiyorum. Sadece vazgeçmeli miyim? ACL tüm sorunlarımı çözer mi ? Yoksa tekrar Ubuntu kullanırken sorun yaşıyor muyum?

Katran kullanarak yapılan yedeklemelerde dikkat edilmesi gereken bir sözcük. Red Hat / Centos dağıtımları, katran programında aklleri destekler, ancak Ubuntu, yedekleme sırasında aklleri desteklemez. Bu, bir yedek oluşturduğunuzda tüm işlemlerin kaybedileceği anlamına gelir.

Sorunlarımı da çözecekse Ubuntu 10.04'e yükseltmeye çok istekliyim, ama önce ne olduğunu anlamak istiyorum.

Yanıtlar:


3

Burada çok şey oluyor olabilir.

İlk düşünceler:

  • evet, pam.d değişiklikleri hemen yürürlüğe girer
  • /etc/pam.d/common-session bir varsayılan belirlemek için en iyi yerdir umask
  • herhangi bir pam.d umask, herhangi bir giriş tarafından geçersiz kılınır .bashrc,
    ancak .bashrcyalnızca belirli koşullar altında okunur (etkileşimli, giriş yapmayan kabuk)
  • testfile (711) çok garip
    • nasıl /homemonte edilir ve ACL'ler mi kullanıyorsunuz?
      (örneğin, ne yazdırır ls -ld /homeve getfacl /homeyazdırırsınız?)
    • did testfilezaten kopya yapmadan önce, çünkü mevcut scpzaten var olduğunu bir dosya izinlerini değiştirmez (kullandığınız sürece -pbayrağı)
  • Nautilus'un dosyaları farklı bir şekilde oluşturduğu biliniyor, neden veya kuralların ne olduğundan emin değilim
  • umask=0113 muhtemelen sorunlara neden olacak
  • ve istemci aynı işletim sistemini mi çalıştırıyor?
    örneğin, istemcide ACL'ler etkinse veya Cygwin ise, davranış farklı olabilir
  • kuvvet aklı başında izinlerine en iyi yolu keşfettiği gibi, aynen, çünkü varsayılan EKL'lerini kullanmaktır umaskkullanıcı tarafından geçersiz kılınan olabilir .bashrcve .bash_profile.

Güncelleme:

  • umask=0113 çünkü sshfs yanlış.
    1. Belirtmeden monte etmeyi deneyin. umask
    2. Kullanarak bağlama noktasının içinde yeni bir dosya oluşturun touch.
    3. Sadece örn. -rw-r--r--, xBitler olmadan aldığını görmelisiniz.
    4. Bitleri maskeleyerek xdizinleri bozabilirsiniz
      ve derleyiciler yürütülebilir dosyaları düzgün oluşturamayabilir

Çözüm:

Daha iyi bir şey düşünemezsek, yaratılan yeni dosyaların izlenmesi famveya gaminizlenmesi ve bunlardaki izinlerin düzeltilmesi için ya da yalnızca periyodik olarak çalışan ve tüm dosyaların izinlerini ayarlayan bir komut dosyası kullanabilirsiniz.


Teşekkürler! Tamam, bu yüzden pam.d / common-sessions dışında TÜM umask ayarlarını kaldırdım . Bu birkaç sorunu çözdü! Test 1 (SCP) ve Test 4 (Nautilus'taki yeni dosya) artık iyi çalışıyor. Engeller artık Nautilus'ta izinleri olan bir dosyayı sunucuya kopyalıyor (Test 3 - 664 yerine hala 777). Ve dizin sorunları. Hem sunucu hem de istemci Ubuntu'dur (9.10'a karşı 10.10) ve ek ACL'ler etkinleştirilmedi.

Nautilus ile kopyalamak gibi sesler gibi cp -pveya izinleri koruyor scp -p.
Mikel

Bunu değiştirmek için herhangi bir fikir ??

Hangi davranışı istiyorsun? Varsayılan ACL'leri kullanarak yeni dosyalar için varsayılan izinleri ayarlayabilirsiniz. Nautilus varsayılan ACL'yi onurlandıracaktır. Bkz vanemery.com/Linux/ACL/linux-acl.html bir bakış ve için suse.de/~agruen/acl/linux-acls/online tüm detaylar için.
Mikel

Varsayılan EKL'lerin maksimum izin kümesini zorlamadığını, yalnızca bu izinleri varsayılan yaptığını unutmayın. cp -p,, scp -pve Nautilus üzerinden kopyalama yine de kopyanın izinlerini kopyalanan dosyayla aynı yapmaya çalışır.
Mikel

0

Bu PAM / umask ile ilgili değildir, ancak sizin için yararlı olabilir.

Eğer varsa setgid Bir dizini, sonra tüm dosyaları ve içindeki oluşturulan dizinleri otomatik olarak gruba atanır.

root@ricarda ~ # mkdir hello      
root@ricarda ~ # chown :users hello 
root@ricarda ~ # chmod g+s hello
root@ricarda ~ # ls -l |grep hello 
drwxr-sr-x. 2 root users  4096 Feb  7 04:05 hello
root@ricarda ~ # touch hello/some_file
root@ricarda ~ # mkdir hello/some_dir
root@ricarda ~ # ls -l hello/       
total 4
drwxr-sr-x. 2 root users 4096 Feb  7 04:16 some_dir
-rw-r--r--. 1 root users    0 Feb  7 04:06 some_file

Teşekkürler! Bunu bilmiyordum. İzin sorunlarını çözmez, ancak gerçekten yararlıdır!


0

EKL'ler sizin için iyi çalışmalıdır.

Daha sonra gelecekteki tüm dosyalar ve dizinler tarafından devralınacak olan grubun tüm klasöründe varsayılan bir EKL ayarlayın.

Gibi bir şey setfacl -m d:g:uploaders:rwxçalışmalı.

Mevcut izinlerinizi düzeltmek için:

find /shared/folder -type d -exec setfacl -m d:g:uploaders:rwx {} \;
find /shared/folder -type f -exec setfacl -m g:uploaders:rw {} \;

Bir dosya kopyalandığında "koru" ayarlanmışsa, varsayılan ACL çalışmaz gibi görünüyor. Bu durumda, yalnızca find komutlarını cron'da çalıştırmayı veya dosya sistemini değişiklikler için izlemeyi öneririm.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.