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

スクリプト内でsudoを実行できるようにrequirettyを無効にしますが、すべてではなく1つのコマンドに対してのみ無効にします。sudoers構成内で可能ですか？

44 sudo 

私はmyhome.sh1行のみを含むbashスクリプトを持っています： echo $HOME スクリプトの所有者はユーザーです： $ ls -l myhome.sh -rw-rw-r-- 1 user user <date> <time> myhome.sh でUbuntuの16.04と17.10私が取得します： $ echo $HOME /home/user $ sudo echo $HOME /home/user $ bash myhome.sh /home/user $ sudo bash myhome.sh /home/user ではDebianのバスター/テスト Iを得ます： $ echo $HOME /home/user $ sudo echo $HOME /home/user $ bash myhome.sh /home/user # …

39 bash  debian  ubuntu  sudo  home 

Fedoraユーザーにsudo特権を与えたい。それ、どうやったら出来るの？

39 fedora  sudo  administration 

Ubuntu 12.04ではsudo -s、$ HOME変数が変更されないため、通常のユーザーがのregularuser場合、状況は次のようになります。 $ cd $ pwd /home/regularuser $ sudo -s # cd # pwd /home/regularuser 私はかなり前にUbuntuを放棄したので、確信はありませんが、これはデフォルトの動作だと思います。だから、私の質問は： Q1。これはどのように行われますか？構成はどこにありますか？ Q2。無効にするにはどうすればよいですか？ 編集： 答えをありがとう、それは少し物事を明確にしたが、私は私が探している答えを得るために、いくつかの質問を追加する必要があると思います。 Q3。Debian sudo -sでは、$ HOME変数をに変更し/rootます。私が答えから得たものとman sudo一緒に走ったシェルsudo -sは、で与えられたもの/etc/passwdですよね？ Q4。ただし、UbuntuとDebianの両方/etc/passwdでrootに指定されたシェルは/bin/bashです。どちらのシステムでも、$ HOMEに関する限り、.profileor .bashrcファイルの違いがどこにあるかを見つけることができないため、の動作がsudo -s異なります。これに関する助けはありますか？

39 ubuntu  sudo  environment-variables 

私のfedora VMで、ユーザーアカウントで実行している場合/usr/local/bin、次のパスにあります。 [justin@justin-fedora12 ~]$ env | grep PATH PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin そして同様に実行するときsu： [justin@justin-fedora12 ~]$ su - Password: [root@justin-fedora12 justin]# env | grep PATH PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin ただし、を介して実行する場合sudo、このディレクトリはパスに含まれません。 [root@justin-fedora12 justin]# exit [justin@justin-fedora12 ~]$ sudo bash [root@justin-fedora12 ~]# env | grep PATH PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/sbin:/bin:/usr/sbin:/usr/bin 経由で実行するとパスが異なるのはなぜsudoですか？

39 linux  shell  sudo  environment-variables  path 

Capistranoを使用してデプロイスクリプトを設定しようとしcap deploy:setupています ステップスクリプトでサーバーに接続し、ディレクトリを作成するコマンドを実行しようとしています。その後、エラーが表示されます：msudo: sorry, you must have a tty to run sudo 私のサーバーでrequirettyを無効にするための推奨される解決策があります。https://unix.stackexchange.com/a/49078/26271 私はそれが安全かどうか疑問に思っていますか？

39 security  sudo  tty 

sudoersでコマンド引数を指定するにはどうすればよいですか？背景として、awsコマンドは実際にはサブシステムの束全体へのゲートウェイであり、ユーザーが実行するだけに制限したいaws s3 cp ...any other args... 私が以下を試してみると /etc/sudoers Cmnd_Alias AWSS3_CMD = /usr/local/bin/aws s3 cp, /usr/local/aws/bin/aws s3 cp gbt1 ALL=(gbt-ops) NOPASSWD: AWSS3_CMD シェルは残念ながらパスワードの入力を求めます $ sudo -u gbt-ops aws s3 cp helloworld s3://my-bucket/hw.1 gbt-ops's password: Cmnd_Aliasのコマンドargsを削除すると、必要に応じて（パスワードプロンプトなしで）流れますが、認証が広すぎます。だから、コマンド呼び出しの唯一の特定の種類に制限する正しい方法は何ですか。 Cmnd_Alias AWSS3_CMD = /usr/local/bin/aws, /usr/local/aws/bin/aws それから $ sudo -u gbt-ops aws s3 cp helloworld s3://my-bucket/hw.1 ...happy …

36 sudo 

サンプルスクリプトは次のようになります。 #!/bin/bash sudo su ls /root ./test.sh通常のユーザーとして使用する場合、代わりにlsスーパーユーザーとして実行して終了し、ルートに切り替えます。ログアウトするls /rootと、通常のユーザーとして実行されます。 誰かがそれについてのメカニズムについて教えてもらえますか？

36 shell  shell-script  sudo  root  su 

sudo環境のセットアップ中に、includeディレクティブの先頭にポンド（＃）文字が付いていることに気付きました。 Solarisはこれを次のように示します。 ## Read drop-in files from /etc/sudoers.d ## (the '#' here does not indicate a comment) #includedir /etc/sudoers.d マニュアル（LinuxおよびSolaris）には次のように記載されています。 sudoers内から他のファイルを含める#includeおよび#includedirディレクティブを使用して、現在解析中のsudoersファイル内から他のsudoersファイルを含めることができます。 そして： その他の特殊文字と予約語ポンド記号（ `＃ '）は、コメントを示すために使用されます（#includeディレクティブの一部である場合、またはユーザー名のコンテキストで発生し、その後に1つ以上の数字が続く場合を除き、その場合、uidとして扱われます）。コメント文字とそれ以降のテキスト（行末まで）は無視されます。 #includeと#includedirディレクティブでポンド文字を使用する選択が行われた理由を誰もが知っていますか？ 副次的注意事項として、私はしばしばegrep -v '^#|^$' configfile、デフォルトではない/アクティブな設定を取得するために何かを使用しますが、これは明らかにsudoersファイルに対して機能しません。

36 sudo 

を使用してファイルを作成するbashスクリプトがありますdd。問題は、ddが大量の出力をスローして、スクリプトの出力を台無しにすることです。周りを検索して解決策を見つけました： dd if=boot1h of="/dev/r$temp1" >& /dev/null 代替手段はあり/dev/nullますか、それとも唯一の方法にリダイレクトしていますか？

35 bash  sudo  su  dd 

ルートユーザーよりも高いアクセス許可を持つユーザーがいると有利だと考えていました。 ご覧のとおり、すべてのアクティビティと既存のほぼすべてのルートユーザー権限を現在の状態のままにしておきたいと思います。 ただし、非常に孤立したケースごとに、rootへの特権を拒否する機能が必要です。 この利点の1つは、更新中に特定の不要なファイルがインストールされるのを防ぐことです。これは、考えられる利点の一例です。 apt-getの更新はrootまたはsudo特権で実行されるため、apt-getには更新中に特定の不要なファイルを置き換える機能があります。 これらの個々の特定のファイルに対するこれらの特権を拒否できる場合は/dev/null、更新中にファイルの置き換えを拒否するアクセス許可を持つ可能性のある空白のプレースホルダーファイルへのsimlinkとして設定できます。 さらに、Ubuntuクリエイターの1人とのインタビューで、ユーザーが「私たち」（Ubuntu開発者を参照）をよりよく信頼する方法について彼が言ったときに言われた行について思い出せずにはいられませんこれは、システムの更新がルート権限で実行される方法への参照でした。 この問題を回避するためにインストール手順を変更するだけでは、私がここで興味を持っていることは絶対にありません。私の心はルートアクセスを拒否する力を持っているという考えを持っているので、それを行うためだけにこれを実現する方法を見つけたいと思います。 私はこれについて考えただけで、これまでこのアイデアに時間を費やしたことはありませんでしたが、これが理解できると確信しています。しかし、これが既に行われたかどうか、またはこれが新しいアイデアや概念ではないかどうかを知りたいです。 基本的に、システムの許可を1度しか超えない許可を持つスーパースーパーユーザーを確保する方法があるはずです。 注：受け入れられた回答は基準に最も適合すると感じていますが、@ CRの回答は本当に気に入っています。また。 ツリー（私）の上位に実際のユーザーを作成したいと思いますが、それを理解する時間ができたら、いつか座らなければならないと思います。 また、ここではUbuntuを選択しようとはしていません。私はそれについて否定的に感じた場合、私のメインのディストリビューションとしてそれを使用しません。

34 permissions  sudo  users  root 

ターンキーlinux redmineを使用してVMをセットアップしました。サーバーにSSHで接続して、いくつかのアイテムをインストールしようとしています。 sudoコマンドを認識していないようです。何かをsudoしようとするたびに、次のエラーが表示されます。 -bash: sudo: command not found 「whereis sudo」と入力するために別の場所を読んだところ、出力は sudo:

33 bash  sudo 

あなたが使用ほとんどすべてのGNU / Linuxディストリビューションでsudo、またはsu、FreeBSDの10のための正しい選択とは何ですか？

32 freebsd  sudo 

sudoerではない場合、Linuxシステムはどのように動作しますか？sudoを使用しようとするとどうなりますか。 server:/tmp>$ sudo cal [sudo] password for user: Sorry, try again. 自分のパスワードがわからないということは可能ですか？（別のマシンシステムでは、私はsudoerではないことが印刷され、インシデントが報告されます）

32 permissions  sudo  root 

「ユーザー名がsudoersファイルにありません。このインシデントは報告されます」という質問と並んで、エラーのプログラム的な側面を説明し、いくつかの回避策を提案しました。 X is not in the sudoers file. This incident will be reported. エラーの前の部分は、明らかにエラーを説明しています。しかし、2番目の部分は「このエラーが報告されます」と言っています。しかし、なぜ？エラーが報告される理由と場所 誰に？私はユーザーと管理者の両方であり、レポートを受け取りませんでした:)！

31 sudo  user-interface