ルートのシェルをデフォルト以外に設定するのは悪い習慣ですか?


16

ある友人(経験豊富なUnix / Linuxユーザー)が、ルートのシェルをsh(つまりbashまたはzsh)以外に設定すると問題が発生する可能性があると私に言った。 。

ただし、Ubuntuではデフォルトのルートシェルがbashに設定されており、Gentooもbashを使用していると思います。誰かが神話をつぶすことはできますか?

回答:


12

はい。起動中にシステムに障害が発生した場合、ルートシェルにログインできます。別個の/ usrがある場合、一部のシェルは正常に起動できません。

toorデフォルトのシェルでルートを残したまま、非標準シェルでアカウント(uid 0、gid 0)を作成することをお勧めします。


これは、FBSD 7.2から8.0にアップグレードしたときに起こり、再構築するのを忘れていましたbash。私は修正するためにシングルユーザーモードで起動しました/bin/shが、まだFBSDフォークのリンクにリンクされていたために機能してbourneいませんでしたbash
gvkv

物事を明確にするために、sayをインストールしてzsh何らかの形/usrで破損した場合、問題が発生しますか?しかし、私のシステムは持っている/bin/shを指し/bin/bashそしてbash、なぜでしょう自体sh影響を受ける可能性?
プネヘヘ

1
システムが起動するルート「保証」のデフォルト-アップグレードガイドは、少なくともルートにログインできるように注意します。ただし、他の場合には当てはまらない場合があります。解決策は、日常的に使用するためにデフォルト以外のシェルでtoorでrootアカウントを複製し、rootのままにすることです。
マチェイピエチョトカ

1
zsh/usr/bin/それが間違ってインストールされた場合は、入ってはいけません。すべてのシェルがでなければなりません/bin
xenoterracide

1
@xenoterracide:Gentooのzshは入っ/binていますが、いくつかのファイルはにあり/usr/shareます。また、問題は起動時のログイン中(一部のサービスが失敗したとき)であることを明確に述べました。
マチェイピエチョトカ

7

問題ではないはずです。

シェルスクリプトファイルは、実行されるシェルを明示的にエンコードします。最初の行にエンコードされるか、他のプログラムまたはスクリプトが特定のシェルを実行し、シェルスクリプトを引数として渡します。

ユーザーアカウントシェル情報を使用する(ログインプロセス以外に)考えられる唯一のプログラムは、procmailです。ユーザーがメールサーバーでshell / bin / falseとして設定している場合は本当におかしいです...しかし、通常はprocmailをルートとして実行しません。

別の候補は、ルートのcrontab内の行です。crondのポリシーがどのシェルを使用するかはわかりません。


通常、$ SHELLは起動時にcrondaemonによって/ bin / shに設定されます。
echox

3

bourneシェル用に作成されたスクリプトは、ほとんどの場合、問題なくBASH、ZSH、または$ fooに対して実行されます。

多くのLinuxシステムでは、オリジナルのshはインストールされていませんが、代わりに/ bin / bashに対するシンボリックリンクであることがよくあります。

一部のスクリプトがシェルが明示的にshであると「想定」している場合、それらを書き換える必要があります。スクリプトに必要なインタープリターを選択するためのシェバンメカニズムがあります。shの場合、スクリプトは#!/bin/sh最初の行として含める必要があります。

このコンテキストでは、デフォルトのシェル設定は関係ありません。


2

ルートのシェルを変更しても問題が生じるとは思わない。ルートのデフォルトシェルとしてtcshを使用しているいくつかのユニセス(おそらくBSDのバリアント?)を覚えているようです。

とにかくルートログインはまれです。通常、自分のアカウントにログインし、suまたはsudoでrootになります。

重要なのは、システムの修復コンテキストで使用できるように、ルートのシェルに可能な限り少ない依存関係を持たせることです。たとえば、静的にリンクされたルートシェルを使用することをお勧めします。一部のディストリビューションには、bashまたはzshまたはsash(多くの標準ユーティリティが組み込まれたシェル)の静的リンクバージョンが付属しています。ただし、レスキューCDまたはUSBドライブからシステムを簡単に起動できる場合、これはそれほど重要ではありません。


依存関係の理由から、大きなシステム変更(アップグレードなど)が混乱しないように、シェルをそのままにしておくのが理にかなっていると思います。ライブCDまたはUSBで修正するのは簡単ですが、そもそも修正する必要はないはずです。
プネヘヘ

1

ユーザーのログインシェルは、ブートプロセスに影響しません。このシェルを任意の値に設定できます。すべてのシステムにbashがあるわけではなく、正常に動作します。また、/usr/bin/zsh誤ってインストールされた場合は、すべてのシステムシェルがにあるはず/binです。ただし、/bin/sh多くのスクリプトが#!/bin/sh通常bashを指している#!/bin/bashため、bashismやその他の振る舞いを使用する必要があるため、デフォルト以外のものを指すように変更しないでください。上の仕事zshdash


おっと残念私は実際に自分のコンピュータ上で、ミスを犯したの両方bashzshしている/bin
phunehehe

0

私が持っているbashのルートのデフォルトのシェルとして。私はしばらくの間zshを使用しましたが、その後bashに戻りました。使用するシェルは重要ではありません。

複数の人がルートアクセス権を持っている場合、これは問題になります。その場合、これは最も広く使用されているシェルであるため、通常はbashである「共通分母」を選択できます。


0

Solaris / illumosに関しては、Solaris Root Shell Mini-FAQ言及

一部のシステム管理者は、
Solarisシステムでルートシェルを変更しないことを推奨しています。理由を尋ねると、rootには / usr / libの下
の動的
ライブラリに依存しない静的にリンクされたシェルが必要であると言われるかもしれません。これは過去に真実でしたが、
必ずしも今日ではそうではありません。Solarisは、適切に構成されている場合、他のバージョンのUnixと同様であり、ルートまたはその他のアカウント用に定義したシェルをサポートできます。

したがって、はい、Solarisまたはillumosを使用している場合は、以外のシェルを使用しても構いませんsh

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.