linux-ext4 - Re: [fuse-devel] [PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND)

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-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1IIdsT-0001dn-00@dorka.pomaz.szeredi.hu>
Date:	Wed, 08 Aug 2007 07:14:37 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	akpm@...ux-foundation.org
CC:	jlayton@...hat.com, codalist@...emann.coda.cs.cmu.edu,
	cluster-devel@...hat.com, jfs-discussion@...ts.sourceforge.net,
	mikulas@...ax.karlin.mff.cuni.cz, reiserfs-devel@...r.kernel.org,
	zippel@...ux-m68k.org, xfs@....sgi.com,
	linux-kernel@...r.kernel.org, wli@...omorphy.com,
	joel.becker@...cle.com, dhowells@...hat.com,
	fuse-devel@...ts.sourceforge.net, jffs-dev@...s.com,
	user-mode-linux-user@...ts.sourceforge.net,
	linux-fsdevel@...r.kernel.org,
	v9fs-developer@...ts.sourceforge.net, linux-ext4@...r.kernel.org,
	linux-cifs-client@...ts.samba.org, ocfs2-devel@....oracle.com,
	bfennema@...con.csc.calpoly.edu
Subject: Re: [fuse-devel] [PATCH 00/25] move handling of setuid/gid bits
 from VFS into individual setattr functions (RESEND)

> >From a purely practical standpoint: it's a concern that all filesytems need
> patching to continue to correctly function after this change.  There might
> be filesystems which you missed, and there are out-of-tree filesystems
> which won't be updated.
> 
> And I think the impact upon the out-of-tree filesystems would be fairly
> severe: they quietly and subtly get their secutiry guarantees broken (I
> think?)
> 
> Is there any way in which we can prevent these problems?  Say
> 
> - rename something so that unconverted filesystems will reliably fail to
>   compile?

Maybe renaming ATTR_MODE to ATTR_MODE_SET (changing it's value as
well, so that binary stuff breaks visibly as well)?

This would make sense, because we are changing what this attribute
acually means.  In the new code attr->ia_mode only contains the
originally set mode, not the ones we've added to change the suid bits.

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html