bash: / dev / stderr: İzin reddedildi

Yeni bir sürümüne geçtikten sonra, bashkomut dosyalarım hata vermeye başlıyor:

bash: /dev/stderr: Permission denied

önceki sürümlerinde Bash ediyorum içten tanımak (bu soru kopyası olmaması bu yüzdendir ki bu dosya adları bu bir ) ve doğru olanı (tm) yapmak , ancak, bu artık çalışmayı durdurdu. Komut dosyalarımı tekrar başarıyla çalıştırabilmek için ne yapabilirim?

Ben gruba komut dosyası çalıştıran kullanıcı ekleme denedim tty, ama bu bile fark (hatta çıkış ve tekrar giriş sonra).

Bunu komut satırında sorunsuz bir şekilde çoğaltabilirim:

$ echo test > /dev/stdout
bash: /dev/stdout: Permission denied
$ echo test > /dev/stderr
bash: /dev/stderr: Permission denied
$ ls -l /dev/stdout /dev/stderr
lrwxrwxrwx 1 root root 15 May 13 02:04 /dev/stderr -> /proc/self/fd/2
lrwxrwxrwx 1 root root 15 May 13 02:04 /dev/stdout -> /proc/self/fd/1
$ ls -lL /dev/stdout /dev/stderr
crw--w---- 1 username tty 136, 1 May 13 05:01 /dev/stderr
crw--w---- 1 username tty 136, 1 May 13 05:01 /dev/stdout
$ echo $BASH_VERSION
4.2.24(1)-release

Eski bir sistemde (Ubuntu 10.04):

$ echo $BASH_VERSION
4.1.5(1)-release

Bunun tamamen bir bash sorunu olduğunu düşünmüyorum .

Bir yorumda, bu hatayı yaptıktan sonra gördüğünüzü söylediniz

sudo su username2

olarak giriş yaptığınızda username. Bu var susorunu tetikleyen söyledi.

/dev/stdoutiçin bir sembolik /proc/self/fd/1bağlantıdır, örneğin bir sembolik bağlantıdır /dev/pts/1. /dev/pts/1sözde bir yalancı olan, ait olduğu ve yazılabilir olduğu username; bu sahiplik, usernameoturum açıldığında verildi . Siz sudo su username2, sahipliğinin /dev/pts/1değişmediği ve username2yazma izniniz olmadığı zaman.

Bunun bir hata olduğunu iddia ediyorum. gerçekte standart çıktı akışı için bir takma ad /dev/stdout olmalıdır , ancak burada echo helloişe yarayan ancak echo hello > /dev/stdoutbaşarısız olan bir durum görüyoruz .

Geçici çözümlerden biri username2, grubun bir üyesi olmak olabilir tty, ancak bu istenmeyen bir durum olan herhangi bir tty'ye username2yazma izni verir .

Başka bir geçici çözüm, username2kullanmak yerine hesaba giriş yapmaktır su, böylece /dev/stdoutyeni tahsis edilen bir sahte sözde işaret eder username2. Bu pratik olmayabilir.

Başka bir geçici çözüm onlar atıfta kalmamak senaryolarınızı değiştirmek olacaktır /dev/stdoutve /dev/stderr; örneğin, şunu değiştirin:

echo OUT > /dev/stdout
echo ERR > /dev/stderr

bundan:

echo OUT
echo ERR 1>&2

Bunu kendi sistemimde, Ubuntu 12.04, bash 4.2.24 ile görüyorum - sistemimdeki bash belgesi ( info bash) bunu söylüyor /dev/stdoutve /dev/stderryönlendirmelerde kullanıldığında özel olarak ele alınıyor . Ancak bash bu isimleri özel olarak ele almasa bile, yine de standart G / Ç akışları için eşdeğer olarak hareket etmelidirler. (POSIX bundan bahsetmez /dev/std{in,out,err}, bu yüzden bunun bir hata olduğunu iddia etmek zor olabilir.)

Bash'in eski sürümlerine bakıldığında, belgeler /dev/stdoutet al'ın dosyalar olsun veya olmasın özel olarak ele alındığını ima eder . Özellik bash 2.04'te tanıtıldı ve NEWSbu sürümün dosyası şöyle diyor:

Yeniden yönlendirme kodu artık birkaç dosya adını özellikle işliyor: / dev / fd / N, / dev / stdin, / dev / stdout ve / dev / stderr, dosya sisteminde bulunup bulunmadığına bakılmaksızın.

Ancak kaynak kodunu ( redir.c) incelerseniz, özel işlemin yalnızca sembol HAVE_DEV_STDINtanımlandığında etkinleştirildiğini görürsünüz (bu, bash kaynağından oluşturulduğunda belirlenir).

Söyleyebildiğim kadarıyla , bash'ın yayınlanmış hiçbir sürümü /dev/stdoutet al'ın özel işlemesini koşulsuz hale getirmedi - bazı dağıtımlar yama yapmadıysa.

Bu yüzden (denemediğim) başka bir geçici çözüm bash kaynaklarını kapmak redir.c, özel /dev/*işlemeyi koşulsuz yapmak için değiştirmek ve sisteminizle birlikte gelenlerden ziyade yeniden oluşturulmuş sürümünüzü kullanmak olacaktır. Yine de, bu muhtemelen aşırıdır.

ÖZET:

İşletim sisteminiz, benimki gibi, sahipliğini ve izinlerini doğru /dev/stdoutve /dev/stderrdoğru işlemiyor. bash sözde bu isimleri yönlendirmelerde özel olarak ele alır, ancak aslında sadece dosyalar yoksa yapar. Eğer bunun bir önemi olmaz /dev/stdoutve /dev/stderrdoğru çalıştı. Bu sorun yalnızca subaşka bir hesaba gittiğinizde veya benzer bir şey yaptığınızda ortaya çıkar; bir hesapta oturum açarsanız, izinler doğrudur.

Aslında bunun nedeni, udev'in tty cihazlarında izinleri özellikle 0620'ye ayarlamasıdır ve su, sahipliğini veya izinlerini değiştirmemelidir. Bana göre bu bizi / dev / std * 'yi taşınabilir olmayan bir durumda bırakıyor.

Basit çözüm "mesg y" / etc / profile (veya kullanmak istediğiniz herhangi bir üst düzey profil) koymaktır, çünkü bu, tty cihazınızın izinlerini 0622 olarak değiştirir. Gerçekten sevmiyorum ama muhtemelen daha iyi udev kurallarını değiştirmek yerine.

Uzun zamandır bir Linux kullanıcısı olarak yakın zamanda yeni bir Ubuntu 64 bit 12.04 LTS sistemi kurdum ve bash betiklerimin neden çalışmadığına - izin verilmedi - ve daha sonra bu iş parçacığını buldum. Sorunun yeni işletim sistemindeki bir şeyden kaynaklanabileceğini düşündüm.

Sonunda benim /homedizinde izinleri ayarlamak için aptalca bir UI aracı kullandığım ortaya çıkıyor ve sorun sürücü ile ilgili. Emin olmak için bir tempdizin oluşturdum /optve komut dosyalarının oradan iyi çalışacağını buldum. /homeSürücü izinlerini sabitledikten sonra her şey normale döndü.

Küçük bir gizem çözüldü. iç çekmek

Bu eski bir soru, ama yine de çok alakalı olduğunu düşünüyorum, bu yüzden burada belirtilmeyen bulduğum çözüm burada.

Ben de bash böyle bir 'su' anahtarlamalı hesap yürütme komutunda sorunlar gördük gibi bu soru geldi:

echo test > /dev/stderr

Yapmaya çalıştığım tek şey stdout'u stderr'e yönlendirmek olduğundan, aşağıdakiler aynı şekilde gerçekleşir ve 'su' anahtarlamalı hesapta bile çalışır:

echo test 1>&2