> From: KillBoy PowerHed <[email protected]> > Hi Dale .. extended attributes are basically key/value pairs, all > the xattr code does currently is a simple regex match against the > names of any extended attributes that may be present for the > file. Capabilities are also stored as extended attributes so the > '-cap' test isspecifically to perform a regex match against the > value of the security.capability extended attribute if it's present.
> My initial use case was to find files that had SUID/SGID capabilities set. > > It actually didn't take long to write the PoC utilities but I'm > happy to accept any suggestions .. If I understand you correctly, "-xattr regex" is true if the file has an extended attribute whose name is matched by "regex". - Is the matching case sensitive? (Is there any reason for it to be case-insensitive?) - Is the nature of the regex controlled by -regextype (as is -regex)? - If the current file name is a symbolic link, does -xattr test the symbolic link itself, or the file it points to? (It's possible that symbolic links can never have extended attributes, in which case looking at the file that is pointed to would always make sense.) Is this behavior affected by the -L option? Or do we need a "-lxattr" test? - Is there any way to test whether a particular attribute has a particular value, or matches a regex? Is there any need for this? If there is: It appears to me that the values can be binary strings; what do we have to do to allow comparison values to be specified (especially given that 0 bytes cannot appear in command arguments). If the values can be binary strings, is there a need to provide a mask-and-test operation? If I understand you correctly, "-cap" is true if there is an attribute with the name "security.capability". The third and fourth questions in the above list apply to that. Dale _______________________________________________ Findutils-patches mailing list [email protected] https://lists.gnu.org/mailman/listinfo/findutils-patches
