web-dev-qa-db-ja.com

rootとしてpythonスクリプトを実行しています

私は次のスクリプトを持っています：

#!/usr/bin/env python                                                           

import sys                                                                      
import pyttsx                                                                   

def main():                                                                     
        print 'running speech-text.py...'                                       
        engine = pyttsx.init()                                                  
        str = "Hi..."                                    
        if len(sys.argv) > 1:                                                   
                str = sys.argv[1]                                               
        engine.say(str)                                                         
        engine.runAndWait()                                                     

if __name__ == '__main__':                                                      
        main()

/usr/bin/speech-test.pyに配置しました

また、rootへの実行可能権限と所有権も付与しました。

Sudo chown root:root /usr/bin/speech-test.py
Sudo chmod 4755 /usr/bin/speech-test.py

ただし、このスクリプトは、Sudo speec-test.pyとして実行した場合にのみ正しく実行されます。 speech-test.pyとして実行しようとすると、ALSAlibファイルの束が見つからないと文句を言います。

スクリプトをroot権限で実行するための何かが足りませんか？

pythonshellrootalsa
5
moesef

したがって、rootがなくても、スクリプトをSudoとして実行する必要がありますか？そのためには、スクリプトのsetuidビットをSudo chmod u+s programで設定する必要があります。ただし、ほとんどのUnixディストリビューションでは、セキュリティ上の理由から、これはバイナリに対してのみ許可されており、スクリプトに対しては許可されていません。一般的に、それを行うのは本当に良い考えではありません。

このスクリプトをrootとして実行する場合は、Sudoとして実行する必要があります。または、スクリプトを実行するバイナリを作成して、このバイナリラッパーにsetuidビットを設定できるようにする必要があります。この 関連する質問 詳細を説明します。

有効なuidを確認し、それがrootでない場合は、実行を停止することもお勧めします。そのために、これを上部近くに追加します（ヒントをありがとう @ efirvida ！）

if not os.geteuid() == 0:
    sys.exit("\nOnly root can run this script\n")

元の回答

たぶん、ユーザーとルートは、異なるバージョンのpython、異なるpythonパス、および異なるライブラリのセットを使用しています。

これを試して：

command -v python
Sudo command -v python

2つのコマンドで同じ結果が得られない場合は、同じバージョンのpython（ALSAライブラリを持つもの）を使用するようにユーザーの設定を変更するか、pythonversionスクリプトの最初の行。

また、スクリプトにprint sys.path行を追加して、ユーザーとSudoで実行して比較してみてください。おそらく、異なる結果が得られるでしょう。ユーザーのPYTHONPATH変数を微調整する必要があるかもしれません。

スクリプトの所有者をルートにし、Sudoで実行する必要はありません。 pythonとPYTHONPATHを正しく設定する必要があります。

10
janos

これが素晴らしい方法かどうかはよくわかりません。私はそれを試しましたが、ArchLinuxで正常に動作します。あなたの考えを聞かせてください。 .pyを別のシステムグループとして実行するスクリプトを作成する場合、そのグループはpythonインタープリターを所有し、指定されたルート機能を持つことができます。

mkdir roottest && cd roottest
Sudo cp /usr/bin/python<ver> ./
Sudo groupadd -r rootpython
Sudo usermod -a -G rootpython <user>
newgrp rootpython
Sudo chown root:rootpython python<ver>
Sudo chmod 750 $bin                       #that way a normal user can't rwx the python interpreter and the rootpython group cant write.
Sudo setcap <caps> ./python<ver>              #now the group has specify caps allowing it to act like root
Sudo getcap ./python<ver>
Sudo sh
touch rootfile && echo "original text" > rootfile

通常のユーザーとして新しいプロンプトを開く

newgroup rootpython
cd roottest && ./python<ver>
>> open('rootfile', 'w').write("different text")
Sudo cat rootfile

pythonはあなたが許可したことしかできず、システムを完全に制御できないため、この方法はSudoよりもはるかに安全です。欠点は、コピーを作成する必要があることです。インタプリタまたは通常のユーザーのグループに使用を許可しない。このようなすべてのpythonコードを実行しないでください。必要がなければ、大きな脆弱性があります。cap_net_admin+ epを使用すると、 kernal var ip_forwardで、上記の例ではcap_dac_override + epが必要です。rootpythonグループに属するnewuserを作成することもできます。そうすれば、newuserのパスワードを入力せずにrootpythonをnewgrpすることはできません。

0
JimiMyFr13nd