[Top][All Lists]

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


Thanks for taking an interest, the feedback is great


reply via email to

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