linux-kernel - 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: <1186533934.6625.91.camel@heimdal.trondhjem.org>
Date:	Tue, 07 Aug 2007 20:45:34 -0400
From:	Trond Myklebust <trond.myklebust@....uio.no>
To:	Andrew Morton <akpm@...ux-foundation.org>
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, 2007-08-07 at 17:15 -0700, Andrew Morton wrote:

> Is there any way in which we can prevent these problems?  Say

The problem here is that we occasionally DO need to add new flags, and
yes, they MAY be security related. The whole reason why we're now having
to change the semantics of setattr is because somebody tried to hack
their way around the write+suid issue.

I suspect we will see the exact same thing will happen again in a couple
of years with Serge's ATTR_KILL_PRIV flag.

> - 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.

Trond

-
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/