1 |
Hi! |
2 |
|
3 |
On Thu, 15 Oct 2015, Jason Zaman wrote: |
4 |
> Can you try this: |
5 |
> |
6 |
> # getfattr -d -m- /bin/ping |
7 |
> security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA= |
8 |
> # setfattr -n user.test -v "foo" ./ping |
9 |
> # setfattr -n user.pax.flags -v "me" ./ping |
10 |
> # getfattr -d -m- /bin/ping |
11 |
> security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA= |
12 |
> user.pax.flags="me" |
13 |
> user.test="foo" |
14 |
> |
15 |
> If this works then something else is causing those messages and we |
16 |
> should look into it further. |
17 |
|
18 |
# cd /bin/ |
19 |
# getfattr -d -m- ./ping |
20 |
# file: ping |
21 |
security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA= |
22 |
|
23 |
# setfattr -n user.test -v "foo" ./ping |
24 |
# setfattr -n user.pax.flags -v "me" ./ping |
25 |
# getfattr -d -m- ./ping |
26 |
# file: ping |
27 |
security.capability=0sAQAAAgAgAAAAAAAAAAAAAAAAAAA= |
28 |
user.pax.flags="me" |
29 |
user.test="foo" |
30 |
|
31 |
But note that emerging iputils does _not_ result in the PaX |
32 |
messages I described. Here's an incomplete list of packages that |
33 |
have triggered them in the past: |
34 |
|
35 |
app-emulation/qemu-2.4.0.1 |
36 |
dev-lang/ghc-7.10.2-r1 |
37 |
dev-lang/python-3.5.0-r1 |
38 |
media-video/mpv-0.11.0 |
39 |
sys-devel/llvm-3.7.0-r2 |
40 |
www-client/firefox-bin-41.0.1 |
41 |
www-client/google-chrome-beta-46.0.2490.64_p1 |
42 |
|
43 |
I have no clue what they do differently from iputils to result in |
44 |
those messages. |
45 |
|
46 |
So I looked at a file mentioned during the llvm merge, |
47 |
/usr/bin/llvm-rtdyld: |
48 |
|
49 |
# getfattr ./llvm-rtdyld |
50 |
# setfattr -n user.test -v "foo" ./llvm-rtdyld |
51 |
# setfattr -n user.pax.flags -v "me" ./llvm-rtdyld |
52 |
# getfattr -d -m- ./llvm-rtdyld |
53 |
|
54 |
Then I remembered that the setfattr might not happen in the live |
55 |
system, but on the tmpfs mounted on /var/tmp/portage. |
56 |
|
57 |
So I tried it there: |
58 |
|
59 |
# cp ./llvm-rtdyld /var/tmp/portage |
60 |
# cd /var/tmp/portage |
61 |
# getfattr -d -m- ./llvm-rtdyld |
62 |
# setfattr -n user.test -v "foo" ./llvm-rtdyld |
63 |
setfattr: ./llvm-rtdyld: Operation not supported |
64 |
# setfattr -n user.pax.flags -v "me" ./llvm-rtdyld |
65 |
setfattr: ./llvm-rtdyld: Operation not supported |
66 |
|
67 |
So it's not a BTRFS problem, but one of tmpfs. So I wondered if I |
68 |
maybe had missed to activate xattr suport for tmpfs, but no: |
69 |
|
70 |
# zgrep -i tmpfs /proc/config.gz |
71 |
CONFIG_DEVTMPFS=y |
72 |
CONFIG_DEVTMPFS_MOUNT=y |
73 |
CONFIG_TMPFS=y |
74 |
CONFIG_TMPFS_POSIX_ACL=y |
75 |
CONFIG_TMPFS_XATTR=y |
76 |
# |
77 |
|
78 |
I have no clue what's missing, since I can't find a mount option |
79 |
or anything that I might have missed: |
80 |
|
81 |
# mount -l -t tmpfs |grep portage |
82 |
none on /var/tmp/portage type tmpfs (rw,relatime,size=8388608k) |
83 |
|
84 |
On a whim, I tried user_xattr, something older ext* FSs support, |
85 |
but alas: |
86 |
|
87 |
# mount -o remount,user_xattr /var/tmp/portage |
88 |
mount: /var/tmp/portage not mounted or bad option |
89 |
|
90 |
In some cases useful info is found in syslog - try |
91 |
dmesg | tail or so. |
92 |
# dmesg|tail -n1 |
93 |
[ 8623.541053] tmpfs: No value for mount option 'user_xattr' |
94 |
|
95 |
Providing =something just results in this: |
96 |
[ 8701.215926] tmpfs: Bad mount option user_xattr |
97 |
|
98 |
So I'm fresh out of ideas. |
99 |
|
100 |
Regards, |
101 |
Tobias |
102 |
|
103 |
|
104 |
|
105 |
|
106 |
|
107 |
-- |
108 |
"Sendmail is the sort of tool that gave UNIX its bad reputation." |
109 |
-- _System Performance Tuning_ |