タグ付けされた質問 「su」

ユーザーの代替コマンド

11
ユーザーのログインを防ぎ、Linuxで「su-user」を許可する方法は?
ユーザーに「su - user」を使用してログインさせ、SSHを使用してログインさせないようにするにはどうすればよいですか? シェルをに設定しようとしました/bin/falseが、試みたときにsu動作しません。 ログインのみを許可する方法はいくつかありますsuか? SSHを使用AllowUserする方法はありますか?(それが行く方法であれば、どのように私はこれをしますか)
93 linux  login  su 

7
nologinシェルを持つユーザーとしてスクリプトを実行します
必要なのは、でnologin/false示されているシェルを持つ特定のユーザーとして特定のスクリプトを実行することだけです/etc/passwd。 スクリプトをルートとして実行し、これは別のユーザーとして実行する必要があります。ランニング: ~# su -c "/bin/touch /tmp/test" testuser 動作しますが、テストユーザーには有効なシェルが必要です。パスワードを無効にしpasswd -d testuserてシェルを/bin/bashこの方法のままにしておくと少し安全になることはわかっていますが、シェルが必要nologin/falseです。 基本的に私が必要なのはcrontab、特定のユーザーがnologin/falseシェルを持っているかどうかに関係なく、特定のユーザーとしてジョブを実行するように設定した場合の処理です。 psこのスレッドはnologinユーザーとしてコマンドを実行していることがわかりましたが、実行する必要があるスクリプトへconcatenateのコマンドのsu -s /bin/sh $user実行方法がわかりません。
87 linux  bash  shell  su  login 

2
nologinユーザーとしてコマンドを実行する
この記事を使用してsuPHPの「仮想」ユーザーがログインできないように、最近サーバーをセットアップしました 私の問題は今、私が実行したときに前にということでrake、私のRuby on Railsのアプリケーションがサーバー上で実行するためのコマンドを、私は使用suに行くことをwww-data理由NOLOGINのもう明らかに私はそれを行うことはできません-そしてそこからコマンドを実行します。 rootユーザーとして、nologinであっても他のユーザーとしてコマンドを実行するにはどうすればよいですか?

2
「スクリプト」を/ dev / null /にリダイレクトすると、「スクリーン」が別のユーザーとしてsuになっているときに機能するのはなぜですか?
特定の長時間実行されるスクリプトを実行するために、ユーザーに夢中になりました。画面を使用したいのですが、「端末 '/ dev / pts / 4'を開けません-チェックしてください」というエラーメッセージが表示されました。 だから私はグーグルで検索して、実行するよう指示されたフォーラムの投稿に出会いました$ script '/dev/null/'。私はそうし、それから私はスクリーニングできた。 なぜこれが機能するのですか?その画面を実行しているsuは、su'edユーザーとして実行できませんか?なぜ 'script'を/ dev / nullにリダイレクトすると、それが妨げられるのですか?スクリプトを使用して、元のユーザーとしてログをどこかに書き込みますか?
37 linux  bash  gnu-screen  su 

1
sudo su-postgresとsudo -u postgresの違いは何ですか?
PostgreSQLユーザーはデフォルトでUNIXソケットでピア認証を行います。UNIXユーザーはPostgreSQLユーザーと同じでなければなりません。したがって、人々は頻繁に使用するsuかsudo、postgresスーパーユーザーになります。 次のような構造を使用している人をよく見ます。 sudo su - postgres のではなく sudo -u postgres -i そして、なぜだろうか。同様に、私は見た: sudo su - postgres -c psql の代わりに sudo -u postgres psql なし大手あなたはせずに、古いプラットフォームにあった場合のバージョンはいくつかの意味になるだろう。しかし、なぜ未定のUNIXまたはLinuxで使用するのでしょうか?sudosusudosudo su
36 postgresql  shell  sudo  su 

2
Linuxの「システム」ユーザーとしてコマンドを実行します(shell = / bin / false)
Ubuntu 11.04(adduser --system)で特定のcronジョブを実行するための「システム」ユーザーを作成しましたが、そのユーザーとしてコマンドを手動で実行してテストすることもあります。これを行う最も簡単な方法は何ですか? suユーザーが/bin/falseそのシェルとして持っているため、動作しません(cronには問題ありません)。/bin/bashテストを行うためにシェルを手動で変更してから、再び元に戻していますが、もっと簡単な方法はありますか?
29 linux  ubuntu  shell  cron  su 

4
BASHスクリプト、単一コマンドのwww-dataへのsu
私が書いたこのブログ投稿で説明されているように、私は Subversionリポジトリと関連するWebサイトの作成の自動化に取り組んでいます。私はwww-dataユーザーにsuして次のコマンドを実行する部分で問題に直面しています。 svnadmin create /svn/repository スクリプトの先頭には、rootまたはsudoとして実行されていることを確認するチェックがあり、それ以降のすべてのコマンドはrootとして実行する必要があります。その1つのコマンドをwww-dataとして実行してから、rootに戻って終了する良い方法はありますか?
26 ubuntu  bash  svn  su 

2
ログインシェルとして別のユーザーにsu中に「ターミナルプロセスグループを設定できません」
注:この投稿の中間地点近くの「編集」で始まる更新情報をお読みください-この問題の環境と背景が変更されました ここに沼地の標準Debian 6.0インストールがあり、Debianテストリポジトリにサイドグレードすることにしました。sources.listのSqueezeリポジトリへの参照を交換して、代わりにTestingリポジトリを使用することでこれを行いました。 パッケージをインストールして再起動した後、suを実行しようとすると次のエラーが表示されます-別のユーザーに対して: root@skaia:~# su joebloggs - bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell -を省略すると、これは発生しません。 ユーザーが正しくrootになることができることに注意してください。これは、rootから他の誰かに切り替えて-を使用してそのユーザーの環境を取得する場合にのみ発生するようです。 Googleはここではほとんど役に立ちません。私が見つけることができるのは、2011年のsuxパッケージに関する参考文献だけです。これは、その間に修正されたようです。 これは、適切なパッケージを適切な方法で調整することで修正できるアップグレードエラーのように見えます。どこから始めればいいのかわからない-これを除けば、私のシステムは完全に正常に動作し、期待どおりに動作します。 編集 上記のように、Debianの安定したマシンでこれが起こっています。今回はアップグレードも何もありません。まっすぐ安定しています。 うん、一年後。一体何が問題なのかまだわかりません。 現在は次のようになっています(変更はほとんどありません)。 bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in …

3
「sudo su-」は悪い習慣と見なされますか?
バックグラウンド 私は違いを知っているsu -、sudo su -とsudo <command>: su - -ユーザーをrootに切り替え、rootパスワードが必要 sudo su - -ユーザーをルートに切り替え、現在のユーザーのパスワードのみが必要 sudo <command>-特定のコマンドに対してのみルートアクセスを許可します。現在のユーザーのパスワードのみが必要 私の質問はsudo su -、実稼働環境で使用することが安全かどうかです。 いくつかの考え: sudo su -ルートアカウントへのアクセスを個々のユーザーパスワードに依存させることにより、許可するとセキュリティリスクが生じるようです。もちろん、これは厳密なパスワードポリシーを適用することで軽減される可能性があります。su -管理者が実際のルートパスワードを共有する必要があるため、これ以上良いとは思いません。 ユーザーが完全にルートアカウントに切り替えることを許可すると、システムに変更を加えたユーザーを追跡するのが難しくなります。私の仕事では、複数のユーザーにsudo su -アクセス権が与えられるケースを見てきました。システムにログインするときにユーザーが最初に行うことは、sudo su -作業を開始する前に実行されることです。それから、ある日、何かが壊れて、誰がrm -rf *間違ったディレクトリで走ったかを追跡することができなくなります。 ご質問 上記の懸念を考えると、ユーザーが使用できるようにすること、sudo su -またはsu -まったく使用できないようにすることは良い考えですか? 管理者が(怠inessは別として)sudo su -またはsu -その代わりにユーザーアカウントを構成する理由はありますsudo <command>か? 注: rootユーザーに対して直接sshアクセスが無効になっている場合、ユーザーが実行している場合、sudo su -またはsu -システムを変更する必要がある管理者である場合は無視します。
13 linux  unix  sudo  su 


8
シェルスクリプト内でsuを使用する
私は展開プロセスを自動化しており、マシン上の.shファイルを1つだけ呼び出して、ビルドを行い、サーバーに.zipをアップロードしてから、サーバー上で多くのことを実行できるようにしたいと考えています。私がしなければならないことの1つは、私がrootになることです。だから、私がやりたいのはこれです: ssh user@172.1.1.101 <<END_SCRIPT su - #password... somehow... #stop jboss service server_instance stop #a bunch of stuff here #all done! exit END_SCRIPT これも可能ですか?
12 ssh  bash  sudo  su 

4
特権Dockerコンテナーを使用したカーネル調整
ロードバランサーのカーネル設定を調整するコンテナーを構築しています。単一の特権コンテナーを使用して、これらの変更をイメージ内のホストにデプロイしたいと思います。例えば: docker run --rm --privileged ubuntu:latest sysctl -w net.core.somaxconn=65535 テストでは変更が有効になりますが、そのコンテナに対してのみ有効です。完全に特権のあるコンテナーを使用すると、/ procを変更すると、実際に基盤となるOSが変更されるという印象を受けました。 $docker run --rm --privileged ubuntu:latest \ sysctl -w net.core.somaxconn=65535 net.core.somaxconn = 65535 $ docker run --rm --privileged ubuntu:latest \ /bin/bash -c "sysctl -a | grep somaxconn" net.core.somaxconn = 128 これは特権コンテナがどのように機能することになっていますか? 私はばかげたことをしているだけですか? 永続的な変更を行うための最良の方法は何ですか? バージョン情報: Client version: 1.4.1 Client API version: …
10 linux  docker  su  sysctl 

2
sshでsu -cを実行します。
SSHを介してサーバーのBIOSバージョンを確認しようとしています。これはroot権限が必要なコマンドです。 ssh remote-server su -c dmidecode しかし、これはもちろんエラーで失敗します: 標準入力はttyでなければなりません これを機能させるにはどうすればよいですか?sudoを使用できません。root@ remote-serverとしてログインしようとすると、suコマンドで使用するパスワードが受け入れられません。RedHat Enterprise Linux 4を使用しています。
10 ssh  unix  su 

2
サーバー管理でsudoまたは単にsu rootを使用する必要がありますか?
どちらのアプローチが優れていますか? デスクトップの使用については、sudoの方が良いようです。 通常のユーザーとしてより一貫した履歴を持つことができます 2つのパスワードを覚えておく必要はありません。これは、管理作業を定期的に行わない場合に特に当てはまります。 インストール時に追加のrootアカウントを作成する必要はありません。 しかし、サーバー管理についてはどうでしょうか? サーバーでは通常、すでにrootアカウントが作成されており、管理作業を頻繁に行う可能性があります。したがって、sudoの利点はもはや保持されていないようです。 さらに、ほとんどのディストリビューションではコマンドラインでsuを設定するのは簡単です。ホイールグループにユーザーを追加するだけです。(あなたも渡すことができ-G wheelたときにuseraddする。)したがって、suコマンドを簡単にシェルスクリプトに自動化することができる設定。 しかし、sudoについては?visudo対話的に実行するよりも、まずユーザーを追加する必要があります。シェルスクリプトに自動化できないため、これは悪いことです。 (まあ、できます。たとえば、 echo '%wheel ALL=(ALL) ALL' >> /tmp/sudoers.tmp cp /etc/sudoers /etc/sudoers.old visudo -c -f /tmp/sudoers.tmp && mv /tmp/sudoers.tmp /etc/sudoers しかし、少なくともそれは簡単ではありません。) だからあなたの意見は何ですか?サーバー環境では、sudoまたはsu rootのどちらを好みますか?
8 unix  sudo  root  su 
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.