linux-kernel - fallocate() on XFS clobbers S*ID-bits

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20101007183418.GC5621@incendiary.meterriblecrew.net>
Date:	Thu, 7 Oct 2010 20:34:19 +0200
From:	Andreas Wiese <aw-lkml@...erriblecrew.net>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc:	Ciaran McCreesh <ciaran.mccreesh@...glemail.com>
Subject: fallocate() on XFS clobbers S*ID-bits

Hello.

I (with support from Cc'ed Ciaran) just noticed some odd behaviour with
fallocate() on XFS.  After open()ing some file and setting it S*ID via
fchmod(), S*ID bits vanish after calling fallocate() — as supposed to
for non-root users, but it also happens for root.

Is this intended behaviour or did we spot a bug here?

At least on ext2 it works as expected, thus I guess it's the latter one.

I'm running v2.6.35.7 vanilla-kernel, but diffing fs/xfs to master
doesn't seem to address this issue.

HAND & LG -- aw
-- 
This signature is intentionally left blank.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/