findutils-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Findutils-patches] xattr and capability support


From: KillBoy PowerHed
Subject: Re: [Findutils-patches] xattr and capability support
Date: Sun, 9 Nov 2014 22:40:41 +0000 (UTC)



>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?)

I initially made it case-insensitive as capabilities are defined
all uppercase in man pages (CAP_XXX) but the output from
cap_to_text() is lower, it seemed reasonable that users may
not know or care what case it was stored in, just whether or
not it was present. What are your feelings on this?

>- Is the nature of the regex controlled by -regextype (as is -regex)?

It's currently hardcoded but I plan to support -regextype, maybe
default to case-insensitive if -regextype is not defined.

>- 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?

Extended attributes are supported on symlinks via a different call
(llistxattr), I guess it should be supported even though there may
not be much demand - is your preference to detect '-L' or offer
 '-lxattr' instead?

>- 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?

This is what '-cap' does, but in the case of capabilities the binary value
needs to be interpreted correctly.
Tools that handle regular expressions as command line arguments
 will always support escaping of non-printing characters, so to match
 a binary '0' you would use '\0' in your regex.

Considering that a given extended attribute's value could contain
 any type of data that may or may not require interpretation I don't
 know that there's value in offering that functionality. Wouldn't this
 also require 2 arguments - <xattr_name> and <regex> ?

>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.



No, cap specifically retrieves the value of security.capability, decodes
it then matches the text value against the regex.

>Dale

Thanks for taking an interest, the feedback is great

Morgan


reply via email to

[Prev in Thread] Current Thread [Next in Thread]