linux-ext4 - Re: [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 for Android: free password hash cracker in your pocket

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

Message-Id: <20070807175402.03ceb0b7.akpm@linux-foundation.org>
Date:	Tue, 7 Aug 2007 17:54:02 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Trond Myklebust <trond.myklebust@....uio.no>
Cc:	Jeff Layton <jlayton@...hat.com>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org,
	v9fs-developer@...ts.sourceforge.net, zippel@...ux-m68k.org,
	dhowells@...hat.com, linux-cifs-client@...ts.samba.org,
	codalist@...EMANN.coda.cs.cmu.edu, joel.becker@...cle.com,
	linux-ext4@...r.kernel.org, fuse-devel@...ts.sourceforge.net,
	cluster-devel@...hat.com,
	user-mode-linux-user@...ts.sourceforge.net,
	mikulas@...ax.karlin.mff.cuni.cz, wli@...omorphy.com,
	jffs-dev@...s.com, jfs-discussion@...ts.sourceforge.net,
	ocfs2-devel@....oracle.com, reiserfs-devel@...r.kernel.org,
	bfennema@...con.csc.calpoly.edu, xfs@....sgi.com
Subject: Re: [PATCH 00/25] move handling of setuid/gid bits from VFS into
 individual setattr functions (RESEND)

On Tue, 07 Aug 2007 20:45:34 -0400
Trond Myklebust <trond.myklebust@....uio.no> wrote:

> > - rename something so that unconverted filesystems will reliably fail to
> >   compile?
> > 
> > - leave existing filesystems alone, but add a new
> >   inode_operations.setattr_jeff, which the networked filesytems can
> >   implement, and teach core vfs to call setattr_jeff in preference to
> >   setattr?
> 
> If you really need to know that the filesystem is handling the flags,
> then how about instead having ->setattr() return something which
> indicates which flags it actually handled? That is likely to be a far
> more intrusive change, but it is one which is future-proof.

If we change ->setattr so that it will return a positive, non-zero value
which the caller can then check and reliably do printk("that filesystem
needs updating") then that addresses my concern, sure.
-
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