This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 651120 - setfattr doesn't accept 0x2 as the value [documentation bug]
setfattr doesn't accept 0x2 as the value [documentation bug]
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: man-pages-overrides (Show other bugs)
6.1
All Linux
low Severity medium
: rc
: ---
Assigned To: Ivana Varekova
BaseOS QE - Apps
: ManPageChange
Depends On: 587516
Blocks: 674870
  Show dependency treegraph
 
Reported: 2010-11-08 15:59 EST by Kamil Dudka
Modified: 2011-05-19 10:28 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 587516
: 674870 (view as bug list)
Environment:
Last Closed: 2011-05-19 10:28:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
upstream commit 846ca47 applied on el6 attr (1.47 KB, patch)
2011-01-27 06:09 EST, Kamil Dudka
no flags Details | Diff

  None (edit)
Description Kamil Dudka 2010-11-08 15:59:01 EST
+++ This bug was initially created as a clone of Bug #587516 +++

Description of problem:
I was trying to set some user.DOSATTRIB values on read-only samba share with setfattr. Samba seems to require the values for that attribute to be hexadecimal, starting with C style 0x prefix. Unfortunately such a value is rejected by setfattr:

gklab-63-001:/var/tmp> setfattr -n user.DOSATTRIB -v '0x2' aqq
bad input encoding
gklab-63-001:/var/tmp> setfattr -n DOSATTRIB -v '0x2' aqq
bad input encoding
gklab-63-001:/var/tmp> getfattr -d aqq
gklab-63-001:/var/tmp> attr -s DOSATTRIB -V 0x2 aqq
Atrybut "DOSATTRIB" dla aqq ustawiono na wartość 3-bajtową:
0x2
gklab-63-001:/var/tmp> getfattr -d aqq
# file: aqq
user.DOSATTRIB="0x2"

Curiously (as seen above) attr -s seems to have no problem with such value.

Version-Release number of selected component (if applicable):
attr-2.4.44-1.fc12.x86_64

How reproducible:
Always

Actual results:
Cannot set the value 0x2 for the attribute.

Expected results:
Can set the value 0x2 for the attribute.


Additional info:
I've also seen this bug on CentOS 5.4 so you should consider cloning the bug there as well.

--- Additional comment from kdudka@redhat.com on 2010-04-30 09:22:39 CEST ---

Thank you for filling the bug!  I'll check if it is a real bug or feature.

FWIW, here is a trace of the failure:

$ gdb -q --args setfattr -n user.DOSATTRIB -v 0x2 /tmp/x
(gdb) break decode
Breakpoint 1 at 0x401839: file setfattr.c, line 291.
(gdb) run

Breakpoint 1, decode (value=0x7fffffffe6cb "0x2", size=0x7fffffffe250) at setfattr.c:291
291             if (value[0] == '0' && (value[1] == 'x' || value[1] == 'X')) {
(gdb) next
292                     const char *v = value+2, *end = value + *size;
(gdb)
296                                          *size / 2)) {
(gdb)
295                     if (high_water_alloc((void **)&decoded, &decoded_size,
(gdb)
302                     d = decoded;
(gdb)
303                     while (v < end) {
(gdb)
306                             while (v < end && isspace(*v))
(gdb)
308                             if (v == end)
(gdb)
310                             d1 = hex_digit(*v++);
(gdb)
311                             while (v < end && isspace(*v))
(gdb)
313                             if (v == end) {
(gdb)
315                                     fprintf(stderr, "bad input encoding\n");
(gdb) info locals
d1 = 2
d0 = 32767
v = 0x7fffffffe6ce ""
end = 0x7fffffffe6ce ""
d = 0x605000 ""
decoded = 0x605000 ""
decoded_size = 256

--- Additional comment from kdudka@redhat.com on 2010-05-11 13:13:55 CEST ---

That's not a bug.  setfattr(1) takes also values in either hexadecimal or base64 format, given the 0[xX] respectively 0[sS] prefix.  You should be able to pass 0x2 as string by surrounding it to quotes.  Please confirm.

I agree there is a dearth of documentation for this feature.  If you had some suggestion what to add to man page or whatever, it would be also appreciated.

--- Additional comment from tomek@jot23.org on 2010-05-11 19:57:58 CEST ---

I would say: it works weirdly:

vesemir:/var/tmp> setfattr -n user.DOSATTRIB -v '0x2' rpm-tmp.P2sHiq
bad input encoding
vesemir:/var/tmp> setfattr -n user.DOSATTRIB -v "0x2" rpm-tmp.P2sHiq
bad input encoding
vesemir:/var/tmp> setfattr -n user.DOSATTRIB -v '"0x2"' rpm-tmp.P2sHiq
vesemir:/var/tmp> getfa
getfacl  getfattr 
vesemir:/var/tmp> getfattr -d rpm-tmp.P2sHiq
# file: rpm-tmp.P2sHiq
user.DOSATTRIB="0x2"

So, to make it work - you need single quotes in doubles quotes, the other way around or plenty of backslashes....

I love hearing: it is not a bug, it is a feature ;).

--- Additional comment from kdudka@redhat.com on 2010-05-11 20:20:11 CEST ---

Sure, that's a feature of the _shell_ you're using ;-)  It drops the outer single or double quotes.  You need to either double quote, or escape the quotes to disable their special meaning:

$ setfattr -n user.DOSATTRIB -v \"0x2\"

You will observe basically the same with e.g. echo(1):

$ echo "0x2"
0x2

$ echo \"0x2\"
"0x2"

--- Additional comment from tomek@jot23.org on 2010-05-11 22:28:00 CEST ---

That doesn't explain why I have to put quotes around 0x2 which is hexadecimal number and not when passing straight string like zzz:

vesemir:/var/tmp> setfattr -n user.DOSATTRIB -v '"0x2"' kdecache-tomek
vesemir:/var/tmp> getfattr -d kdecache-tomek
# file: kdecache-tomek
user.DOSATTRIB="0x2"

vesemir:/var/tmp> setfattr -n user.DOSATTRIB -v zzz kdecache-tomek
vesemir:/var/tmp> getfattr -d kdecache-tomek
# file: kdecache-tomek
user.DOSATTRIB="zzz"

My understanding is that all attributes are just strings and I consider the requirement to quote hexadecimal number in this case unreasonable.

But that's another story, I think you can close the bug (unless you agree with me and want to fix it ;) ).

--- Additional comment from kdudka@redhat.com on 2010-05-11 23:17:30 CEST ---

Well, my mistake.  I should have explained this properly.

The mentioned feature is obstruction from your point of view since you pass only text values through.  Nevertheless there should be a way to pass some binary values as well.  That's why the hexadecimal and base64 format has been introduced, at least from my understanding of that.

Each enhancement has its cost.  In this case, it means that all strings starting with '0x', '0X', '0s', or '0S' are treated specially.  To get the old behavior back, just surround your value by double quotes.  It will work well for "0x2", as well as "zzz".

If you have any idea how to implement the feature in a better way (without breaking the stuff), patches are welcome.  I left the bug open because I hadn't found the feature mentioned in documentation.  If the information is indeed missing, we should perhaps a paragraph there about the feature.

FWIW, I've CC'd the upstream maintainer of attr.

--- Additional comment from kdudka@redhat.com on 2010-11-08 20:25:06 CET ---

Created attachment 458858 [details]
proposed improvement of setfattr.1 man page
Comment 1 Kamil Dudka 2010-11-09 03:09:08 EST
Created attachment 459025 [details]
[PATCH v2] proposed improvement of setfattr.1 man page

just fixed two typos...
Comment 3 Kamil Dudka 2011-01-27 06:09:31 EST
Created attachment 475581 [details]
upstream commit 846ca47 applied on el6 attr
Comment 7 errata-xmlrpc 2011-05-19 10:28:56 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0780.html

Note You need to log in before you can comment on or make changes to this bug.