web-dev-qa-db-ja.com

ローカルシステムアカウントとしてテストする方法は? (Pythonからリモートファイルにアクセスする)

Webアプリケーションサーバーからいくつかのリモートファイルにアクセスしようとしています。それらをサーバーMおよびRと呼びましょう。どちらもWindowsServer(2008および2003)を実行しています。

リモートファイルは、Everyoneが読み取り可能なファイル共有上のサーバーRにあります(共有アクセス許可とセキュリティアクセス許可により、Everyoneが読み取ることができます)。この共有は\\R\EthReleaseと呼ばれます。

WebアプリケーションはサーバーMにあります。私はTomcatサーブレットコンテナの下でPython(本当にJython)スクリプトを実行しています( [〜#〜] bsf [〜#〜] 経由) Rのリモートファイルにアクセスします。

しかし、私が何をしても、スクリプトはリモート共有フォルダーを見ることができません。例:私はPython次のようなコードを使用します:

# Note, R: is a mapped network drive pointing to \\R\EthRelease
for file in ['C:', 'C:\\', 'C:\\Users', 'R:', 'R:\\',
        r"\\R\EthRelease", r"\\172.x.x.x\EthRelease"]:
    output.append("  <accessCheck dir='%s' exists='%s' accessF='%s' accessR='%s'/>\n" %
        (file, os.path.exists(file), os.access(file, os.F_OK),
        os.access(file, os.R_OK)))

スクリプトが存在すると言うフォルダはC:\C:\Usersだけです。

<accessCheck dir="C:" exists="False" accessF="False" accessR="False"/>
<accessCheck dir="C:\" exists="True" accessF="True" accessR="True"/>
<accessCheck dir="C:\Users" exists="True" accessF="True" accessR="True"/>
<accessCheck dir="R:" exists="False" accessF="False" accessR="False"/>
<accessCheck dir="R:\" exists="False" accessF="False" accessR="False"/>
<accessCheck dir="\\R\EthRelease" exists="False" accessF="True" accessR="True"/>
<accessCheck dir="\\172.x.x.x\EthRelease" exists="False" accessF="False" accessR="False"/>

対照的に、サーバーMのCMDプロンプトで上記のパスのいずれかでdirを実行すると、それらは存在し、読み取り可能です。

C:\Users\me>dir r:\
 Volume in drive R is GIS
 Volume Serial Number is ...

 Directory of r:\

12/03/2012  09:18 AM    <DIR>          .
12/03/2012  09:18 AM    <DIR>          ..
07/25/2013  08:51 AM    <DIR>          EGI
12/17/2013  05:46 AM    <DIR>          maps
               0 File(s)              0 bytes
               4 Dir(s)  48,192,491,520 bytes free

C:\Users\me>

Jython安定版2.5.3とJythonベータ版2.7b1の両方でこれを試しましたが、同じ結果が得られました。ラップトップで同様のコマンドを実行し(Python 3.3)を使用)、同じネットワーク共有に正常にアクセスできるため、これはPythonの問題だけではないことを知っています。 。

考えられる違いの1つは、サーブレットコンテナであるTomcatがサーバーMでローカルSYSTEMユーザーとして実行されているのに対し、CMDシェルでは別のユーザーとしてログインしていることです。しかし、前述のように、Everyoneはリモートファイル共有にアクセスできるので、違いはありませんよね? SYSTEMユーザーとしてログインし、その状態でリモートファイル共有にアクセスできるかどうかをテストする方法はありますか?

もう1つの考えられる違いは、サーブレットコンテナまたはBSFが何らかのサンドボックス制限を課し、サーブレットコンテナの外部のファイルにアクセスできない可能性があることです。しかし、私はC:\をチェックできるので、それは起こっていません。

何か案は??これは私を壁に押し上げてきました。以前、 Cocoon 内から直接ファイルにアクセスし、同じ種類の壁にぶつかってみました。最近、「ユーレカ!問題をPythonスクリプト!Pythonで処理できます!」にアウトソーシングできますが、これまでのところ、サイコロはありません。

1
LarsH

これらのスーパーユーザーの質問で説明されているように– 昇格されたコマンドラインプロンプトはWindows 7の共有ドライブにアクセスできません および Windows 7の昇格されたプロセスからネットワーク共有にアクセスする方法? –ドライブマッピングはログインに関連付けられているため、特別な調整を行わない限り、SYSTEMにはそれらがありません。 UNCを使用するか、コードからNet Useを実行して、リモートファイルを操作する必要がある場合があります。テストプログラムは、FおよびR\\R\EthReleaseにアクセスできることを報告していることに注意してください。

2
Scott

私は通常、この目的でローカルシステムアカウントを使用することは検討しません。このアクセスを提供するために、networkserviceアカウントまたはマネージドサービスアカウントで実行することを検討します。

これをテストするために本当にローカルシステムアカウントとしてログインしたい場合は、ローカルシステムアカウントとしてシェルを開く方法がいくつかあります。

PSTools にある [〜#〜] psexec [〜#〜] を使用して、システムアカウントでインタラクティブなcmdセッションを開くことができます:psexec -i -s cmd.exe

または、システムアカウントとして実行されているスケジュールされたタスクを開始します(at <time> /interactive cmd.exe

1
Rex