Mailing List Archive

Yeah, I think that's a good improvement. Same happened to me having tmp as
tmpfs which didn't have that option turned on. A lot of mess began.
Am 13.06.2014 16:40 schrieb <subscryer@gmail.com>:

> I suggest a little improvement to the wiki: state the fact that user_xattr
> must be enabled in fstab for the relevant filesystems (at least /) as this
> isn't default AFAIK. I stumbled into this problem today and at first I
> couldn't understand what was happening.
>
> Thanks for your work.
>
>

On 06/13/14 10:40, subscryer@gmail.com wrote:
> I suggest a little improvement to the wiki: state the fact that
> user_xattr must be enabled in fstab for the relevant filesystems (at
> least /) as this isn't default AFAIK. I stumbled into this problem today
> and at first I couldn't understand what was happening.
>
> Thanks for your work.

I haven't fully understood why sometimes you need to add this and
sometimes you don't --- kernel versions? Different arches?

Nonetheless, you're right on this.

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

On 13 Jun 2014 at 16:40, subscryer@gmail.com wrote:

> I suggest a little improvement to the wiki: state the fact that
> user_xattr must be enabled in fstab for the relevant filesystems (at
> least /) as this isn't default AFAIK.

i already forcibly enable the general xattr support in filesystems in
the kernel .config when the xattr based control method is enabled, i
could also forcibly enable user xattrs on actual mounts. the question
is whether such a policy decision belongs in the kernel or not...

On 06/14/14 06:49, PaX Team wrote:
> On 13 Jun 2014 at 16:40, subscryer@gmail.com wrote:
>
>> I suggest a little improvement to the wiki: state the fact that
>> user_xattr must be enabled in fstab for the relevant filesystems (at
>> least /) as this isn't default AFAIK.
>
> i already forcibly enable the general xattr support in filesystems in
> the kernel .config when the xattr based control method is enabled, i
> could also forcibly enable user xattrs on actual mounts. the question
> is whether such a policy decision belongs in the kernel or not...
>

I was going to say "no this doesn't belong in the kernel" but actually
yeah, maybe it does. If we are going to enable xattr support on
filesystems when we want XATTR_PAX, then we should enable user.* xattr
support on mounts. The other xattr namespaces are already enabled on
those filesystems, so why not add user.*? One caveat I can think of is
we only need user.pax.flags while we'd be turning on all of user.* so
maybe some perverse attack could make use of user.exploitme or something
like that? (I'm stretching it, I know.) Also we'd be removing the
choice to mount nouser_xattr and effectively force all markings off. Or
you could just change the default behavior of mount to mount -o
user_xattr and the user would then have to mount -o nouser_xattr to turn
user.* off.

Comments?

--
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197