Project

General

Profile

Bug #10993

SMB can't view permissions when owners not in /etc/passwd

Added by Gordon Ross 5 months ago. Updated 5 months ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Start date:
2019-05-14
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

Description:

On multi-protocol shares in which the there is no mapping for UID's to UNIX username and no mapping set from SID to UID via idmap, ownership and ACL information cannot be viewed from Windows unless an ACL exists with inherited permissions.

Even if ACL's are explicitly set with the same permissions, no information is provided.

Steps to Reproduce:

1. Create a share (aclmode=passthrough, aclinherit=passthrough, atime=off)
2. Share via NFS
3. Share via SMB
4. Create a file via NFS with an owner that does not resolve to a username on the NexentaStor or simply touch a file on the share via bash and change owner:group to a numerical UID:GID.
5. View the file via Windows Explorer and right click on Properties then Security to show ACL entries.
6. From bash, remove the inhertied flag from the permissions but leave the permissions the same.
7. Attempt to view the Security properties again.

Expected Results:

Security Properties should be visible and though attempting to view the owner no owner information is displayed but the user can take ownership regardless of if the ACL granting access is inherited or not.

Actual Results:

If the ACL is inherited, Security information can be viewed and ownership of the file can be taken.

If the ACL is explicitly set but not inherited, a message of "The Requested Security Information is either unavailable or can't be displayed"

History

#1

Updated by Gordon Ross 5 months ago

  • Description updated (diff)
  • Status changed from New to In Progress
#2

Updated by Gordon Ross 5 months ago

Analysis from Matt Barden

Dtrace logs reveal that the GetSecInfo request on "nfsfile" fails with NT_STATUS_NONE_MAPPED. The dtrace output indicates this comes from smb_sd_fromfs when either of the smb_idmap_getsid calls fail. In this case, the call is failing with IDMAP_ERR_NOTFOUND, likely because of the lack of uid->sid mapping. This error bubbles up to be the result of the GetSecInfo request.

One relevant function that returns this is ns_lookup_bypid; it attempts to retrieve the unixname from a uid using getpwuid_r. if this call fails (as it would if there's no entry, like in our case), the function returns IDMAP_ERR_NOTFOUND. pid2sid_first_pass calls this if the lookup is in AD_MODE. pid2sid_second_pass always calls this if the unixname has not already been found. Both of these are called by idmap_get_mapped_ids_1_svc, which is where we should end up at the other side of this doorcall.

idmap uses passwd entries to map uids to unixnames for handling name-based mappings; when no entry is found for a uid, it returns IDMAP_ERR_NOTFOUND. When idmap returns IDMAP_ERR_NOTFOUND, it generates a "local sid", but still returns an error. This local sid is valid and can be used by the caller. The solution is for SMB to check for the presence of this localsid and use it if it exists, rather than ignoring it and failing the request.

#3

Updated by Gordon Ross 5 months ago

Verified at the customer.
Fix in production since early 2017

#4

Updated by Electric Monk 5 months ago

  • Status changed from In Progress to Closed
  • % Done changed from 0 to 100

git commit a88046d1e68acaef04dc4175c8e09654bd94b8e9

commit  a88046d1e68acaef04dc4175c8e09654bd94b8e9
Author: Matt Barden <matt.barden@nexenta.com>
Date:   2019-06-01T16:44:37.000Z

    10993 SMB can't view permissions when owners not in /etc/passwd
    Reviewed by: Gordon Ross <gordon.ross@nexenta.com>
    Reviewed by: Yuri Pankov <yuri.pankov@nexenta.com>
    Approved by: Richard Lowe <richlowe@richlowe.net>

Also available in: Atom PDF