为什么“本地系统”帐户缺少NTFS文件系统的权限（将java作为Windows服务运行）

Question

I have a problem running a java process as a windows service due to NTFS permissions. (http://community.jboss.org/wiki/RunJBossAsAServiceOnWindows).

The service installs successfully, but has problems starting due to file permissions.

• If I change the windows-service "login" to my account (eg domain/login), the service runs fine.
• If I change the filesystem permisisons from 755 to 777, the service runs fine.

Example log

08:58:02,250 ERROR [MainDeployer] Could not make local copy for file:/J:/projects/devtools/pe64-jboss-4.2.2.GA/server/solr/conf/jboss-service.xml
java.io.IOException: Access is denied
    at java.io.WinNTFileSystem.createFileExclusively(Native Method)

"Yo No Comprende". I thought the "Local System" account was "root". ("Local System" is the default account)

"chmod -R 777 <>" is not an option. (security hole)

So to summarize:

• What is the deal with "Local System" and windows NTFS file permissions?
• Can you add "Local System" to "My group"
• Is my local build process doing something wrong? (eg the windows version of UMask is bad? )
• Any other gotchas running java as a windows service?
• After 15+ years of windows NT-based OS, why are services still such a pain?

Update/Solution

It turn out that in later Windows (Vista and Window 7), MSFT closed a security hole which allowed a service to get at anyone's "temp" files.

"Local System" account just doesn't have access to any common/pre-created "temp" directory.

The solution, in the java world:

• create your own temp directory. Grant it adequate permisions)
• pass "-Djava.io.tmpdir=/path/to/my/temp/dir" as a jvm argument.

thanks

will

Answer 1

"Local System" isn't exactly root. It can be denied (or not granted) permissions, just like any other user, and Windows will enforce those permissions. (Though you better know what you're doing before you do so -- blocking the wrong stuff from it can make your system unusable.) Sometimes, often when you're copying stuff from a privileged location (like your desktop or something), Windows will turn off the "inherit permissions" thingie for the folder, and the account won't get the permissions it'd normally inherit from the root.

Make sure the folder grants the Local System account permission to add files to the folder where it wants to create that file. As for how you'd do that with Cygwin...i'm not sure. Does it have something akin to Linux's setfacl command ?

Answer 2

NTFS permissions work a bit differently than Ext2/3/4 permissions.

Specifically, the file system doesn't care if you're an administrator or not... if your SID doesn't have the Create Files permission or one of the other meta-permissions that include it (ie Write ) on a directory, you can't create a new file or copy a file from another directory to said folder.

What it does give you is the permission to change the permissions on any folder.

Answer 3

I wouldn't use Cygwin for this. Instead, I use a combination of cacls and ntrights (from the XP resource kit - still works in 2008 / win 7). The only issue is that you have to run Ant as an administrator. This means that you need to either make sure you start an admin level cmd prompt or your installer has to to elevate.

In Ant, I do something like the following:

<!-- give the service user full access to install dir -->
<exec executable="cacls" failonerror="true" osfamily="winnt" output="NUL">
  <arg line="&quot;${dir.install}&quot; /e /p ${service.username}:f" />
</exec>

<!-- remove the Users group access from the install dir -->
<exec executable="cacls" failonerror="true" osfamily="winnt" output="NUL">
  <arg line="&quot;${dir.install}&quot; /e /t /r Users" />
</exec>

<!-- give the service user the right to log on as a service,
     remove right to logon through the UI -->
<exec executable="${dir.installer}/install/ntrights">
  <arg line="-u ${service.username} +r SeServiceLogonRight" />
</exec>
<exec executable="${dir.installer}/install/ntrights">
  <arg line="-u ${service.username} +r SeDenyInteractiveLogonRight" />
</exec>

Note that I couldn't get cacls to work with individual args. I had to specify the whole line. Also note the quote escape to handle directories with spaces (eg Program Files).