Project

General

Profile

Actions

Bug #16546

open

The find command should be able to find SIDs

Added by Bill Sommerfeld 17 days ago. Updated 16 days ago.

Status:
In Progress
Priority:
Normal
Category:
cmd - userland programs
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
External Bug:

Description

Inspired in part by #15027 and a need to clean up acls on a SMB share I coded this up a while back.

I added -gsid, -gsidacl, -usid, and -usidacl options, parallel to existing options that match on gid/uid. The implementation feed the option's argument to sid_to_id to generate an ephemeral id for matching.

Actions #1

Updated by Electric Monk 17 days ago

  • Gerrit CR set to 3469
Actions #2

Updated by Gordon Ross 16 days ago

Do any other systems have similar find options?

I'm wondering about the purpose of distinguishing user vs group SIDs when searching ACLs.
The whole business of user vs groups is often fiction when it comes to SIDs in ACLs.
Might we be better off with a find option that returns true if the SID appears in any type of ACE?
(not specifically a "user" SID ACE or a "group" SID ACE -- there are many ACE types...)

For background, a SID can represent several different things: a user, a group, an alias, ...
and our system "shoe horns" those into user or group, with group as the usual fall-back.

On the other hand, I suppose "usidacl" parallels "useracl" (and "gsidacl" / "groupacl")

Actions #3

Updated by Bill Sommerfeld 16 days ago

Do any other systems have similar find options?

I did an (admittedly cursory) search and only found references to Windows CLIs for this. There doesn't seem to be anything in GNU find.

Might we be better off with a find option that returns true if the SID appears in any type of ACE?

BTW, a while back I fixed #15353 that would have given you this by accident.

I'll add a -sidacl option that is equivalent to \( -usidacl X -or -gsidacl X \)

(not specifically a "user" SID ACE or a "group" SID ACE -- there are many ACE types...)

I just refreshed my memory of how the ACE types are encoded in ace_t. It's convoluted -- aspects of the ACE "type" are split between two structure fields. I believe that the existing code will find any reference to a SID that either is or is not marked as a group regardless of the a_type of the ACE - so I think that what you want with regards to ACE types is already there.

The existing test to see if an ACE matched an id in find.c is:

    if (p2->a_who == np->first.l && ((p2->a_flags & ACE_TYPE_FLAGS) == t2))

where t2 is either 0 or ACE_IDENTIFIER_GROUP depending on whether or not we're looking for a user or a group SID.

The definition of ACE_TYPE_FLAGS is (ACE_OWNER|ACE_GROUP|ACE_EVERYONE|ACE_IDENTIFIER_GROUP);
OWNER and GROUP are the id-less ACEs that refer to the file owner and group (st_uid and st_gid in struct stat) - so this mainly excludes ACEs that doesn't have an ID.

Notably we are only looking at the "type flags" in a_flags, and not at the "type" in a_type; the latter has a set of possible values that includes "allow", "deny", "audit", and "alarm".

I'll extend the test to confirm this and fix the man page to make this more clear.

Actions #4

Updated by Bill Sommerfeld 16 days ago

BTW, a while back I fixed #15353 that would have given you this by accident.

Actually, no, it wouldn't have. idmap maintains separate SID to uid and SID to gid mappings; a single SID may map to both a uid and a gid and they are likely different if assigned ephemerally:

: 1 #; chown -s S-1-5-21-11111111-22222222-33333333 a
: 1 #; chgrp -s S-1-5-21-11111111-22222222-33333333 b
: 1 #; chgrp -s S-1-5-21-44444444-55555555-66666666 a
: 1 #; chown -s S-1-5-21-44444444-55555555-66666666 b
: 1 #; ls -n
total 2
drwxr-xr-x   2 S-1-5-21-11111111-22222222-33333333 S-1-5-21-44444444-55555555-66666666       2 May 10 09:47 a
drwxr-xr-x   2 S-1-5-21-44444444-55555555-66666666 S-1-5-21-11111111-22222222-33333333       2 May 10 09:47 b
: 1 #; ls -nn
total 2
drwxr-xr-x   2 2147483651 2147483655       2 May 10 09:47 a
drwxr-xr-x   2 2147483652 2147483656       2 May 10 09:47 b

This makes -sidacl a bit more complex but I'll figure it out.

Actions

Also available in: Atom PDF