linux-kernel - Re: [RFC 02/22] configfs: Add struct configfs_item_operations->check_link() in configfs

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]

Date:	Tue, 7 Sep 2010 15:44:13 -0700
From:	Joel Becker <Joel.Becker@...cle.com>
To:	Konrad Rzeszutek Wilk <konrad@...nok.org>
Cc:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	Mike Christie <michaelc@...wisc.edu>,
	Christoph Hellwig <hch@....de>, Hannes Reinecke <hare@...e.de>,
	James Bottomley <James.Bottomley@...e.de>,
	Jens Axboe <axboe@...nel.dk>,
	Boaz Harrosh <bharrosh@...asas.com>,
	Linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [RFC 02/22] configfs: Add struct
 configfs_item_operations->check_link() in configfs_unlink()

On Tue, Sep 07, 2010 at 05:01:01PM -0400, Konrad Rzeszutek Wilk wrote:
> > > 	I NAK'd this a while back.  I'm willing to be convinced, but so
> > > far it remains that way.
> >
> > Hi Joel,
> >
> > Thanks for bringing this point up again.  So a brief refresh on why this
> > is currently required in the fabric independent configfs handlers in
> > drivers/target/target_core_fabric_configfs.c (patch #19).
> 
> Well, that is great that you mentioned your requirements. But I don't see a 
> quote of Joel's concerns? Is there an LKML link for it perhaps?

	It was a while back.  Essentially, the concern is that configfs
is defined to be userspace-driven.  If the user asks you to remove
something, the module should be handling safe teardown rather than
rejecting the user's request.
	Now, the world isn't always clean-cut.  Code outside of the
filesystem representation can lay a claim on a configfs item to say "I'm
busy with this."  An example is ocfs2 pinning the configfs item
describing its cluster heartbeat device.   But this is ocfs2 - a
separate thing - claiming it.  There is a defined API to take and
release these claims.
	This API doesn't cover symlinks, as symlinks are simply linkage
between config items.  It may be, as Nick suggested at the bottom of his
reply, that we want the API extended to cover that case.  But he hasn't
yet convinced me that safe teardown is impossible or disasterous.
That's what I'd like to see.  It's not obvious on the face of all the
file trees in the email.
	Nick, can you provide some form of description, not long
pathnames, that explains a) what breaks when the symlink is removed b)
why that can't be allowed if the user is dumb enough to request it?

Joel

-- 

"The lawgiver, of all beings, most owes the law allegiance.  He of all
 men should behave as though the law compelled him.  But it is the
 universal weakness of mankind that what we are given to administer we
 presently imagine we own."
        - H.G. Wells

Joel Becker
Consulting Software Developer
Oracle
E-mail: joel.becker@...cle.com
Phone: (650) 506-8127
--
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/