在检查samba装载的权限时，Java是否完全兼容？

Question

我正在使用

Files.isWritable(file)

在我的Java应用程序中检查我是否有权在修改文件之前修改文件。

这通常可以正常工作，但我有一个客户抱怨说虽然他已经完全允许他的文件，但它仍然无法正常工作。客户设置包括一个安装有Samba的远程Linux驱动器到他的Windows机器，我的软件在Windows机器上运行。

事实证明，他已经为特定用户的文件夹和文件授予了完全权限，但不是用户组或Linux上的任何其他人。

如果他将linux上的权限从700改为777，那么它有效但我不确定他是否应该这样做？

在检查samba挂载的权限时是否存在Java问题

Answer 1

取决于。

UNIX和Windows上的访问控制机制传统上是不同的。以前，与samba3一样，您在这些权限之间有一个相当粗略的映射，这在较简单的情况下起作用，但在更困难的情况下有问题。您可以找到许多处理这些特殊情况的教程，论坛帖子和邮件列表。

现在，事情变得更好了，因为NFSv4风格中有访问控制列表。优点有几个：

• 它就像一个界面：你对不同的系统拥有相同的权限“想法”，并且它们实现了自己的文件系统相关细节，这意味着你（或Java）只需要处理高级别的东西。
• 它比旧的基本UNIX权限更灵活，包括创建新文件或创建新子目录，文件和/或目录的详细继承，或者拒绝并允许组合规则。
• 尽管有这个名字，它不仅适用于NFS版本4，还适用于当前的Windows权限，ZFS上的Solaris 10 / illumos CIFS实现和Linux系统上的samba4（我相信）。

您通常使用ACLFileAttributeView，如简短示例中所述：

 // lookup "joe"
 UserPrincipal joe = file.getFileSystem().getUserPrincipalLookupService()
     .lookupPrincipalByName("joe");

 // get view
 AclFileAttributeView view = Files.getFileAttributeView(file, AclFileAttributeView.class);

 // create ACE to give "joe" read access
 AclEntry entry = AclEntry.newBuilder()
     .setType(AclEntryType.ALLOW)
     .setPrincipal(joe)
     .setPermissions(AclEntryPermission.READ_DATA, AclEntryPermission.READ_ATTRIBUTES)
     .build();

 // read ACL, insert ACE, re-write ACL
 List<AclEntry> acl = view.getAcl();
 acl.add(0, entry);   // insert before any DENY entries
 view.setAcl(acl);

在您的情况下，从第二步查询您想要检查的权限的视图就足够了。有关详细的概述，我喜欢使用此documentation from Oracle - 虽然示例来自chmod，但Java中的权限本身是相同的（但是它们也存在较短的JavaDoc，{{3} }）。