linux-kernel - Re: [PATCH][RFC 5/23]: SCST /proc interface

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:	Fri, 12 Dec 2008 22:23:16 +0300
From:	Vladislav Bolkhovitin <vst@...b.net>
To:	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>
CC:	linux-scsi@...r.kernel.org,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	Mike Christie <michaelc@...wisc.edu>,
	Jeff Garzik <jeff@...zik.org>,
	Boaz Harrosh <bharrosh@...asas.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, scst-devel@...ts.sourceforge.net,
	Bart Van Assche <bart.vanassche@...il.com>,
	Joel Becker <joel.becker@...cle.com>
Subject: Re: [PATCH][RFC 5/23]: SCST /proc interface

Nicholas A. Bellinger wrote:
> On Wed, 2008-12-10 at 21:37 +0300, Vladislav Bolkhovitin wrote:
>> This patch contains SCST the /proc interface.
>>
>> A description of this interface can be found in the patch with the
>> SCST core documentation.
>>
>> Since a procfs-based configuration interface is unacceptable for new 
>> kernel modules, in the next review iteration SCST's configuration 
>> interface will be replaced by a sysfs-based configuration interface. 
>> This patch is not intended to be included in the Linux kernel, but is 
>> posted here, because as of today this configuration interface is 
>> necessary when using SCST.
>>
>> Unfortunately, configfs is not (yet) suited for configuring SCST. This 
>> is, because configfs is user space driven, so kernel can't create 
>> subdirectories on it, and all files on configfs are limited to 4K in 
>> size. It makes impossible for kernel to show, e.g., a list of connected 
>> initiators. Hence, with configfs it is necessary to have one more 
>> interface to show such data, e.g. sysfs-based. 
> 
> Btw, please stop spreading FUD about ConfigFS.  ConfigFS works great for
> Target_Core_Mod and LIO-Target v3.0, and is what I have found as the
> *BEST* foundation for generic target mod moving forward.  This is not
> based on a hypothetical discussion or on a long term TODO list, this has
> been determined from actually writing the code, which is located at:
> 
> http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=blob;f=drivers/lio-core/target_core_configfs.c
> 
> http://git.kernel.org/?p=linux/kernel/git/nab/lio-core-2.6.git;a=blob;f=drivers/lio-core/iscsi_target_configfs.c
> 
> So please, just because you don't want to acknowledge ConfigFS in your
> own work, do not act like there is not already thounsands of lines of
> ConfigFS code up and running for the generic target mode and LIO-Target.

Nicholas,

You have an *exceptional* ability don't see what you don't want to see. 
It has already happened with Persistent Reservations over pass-through 
backend (see the end of http://lkml.org/lkml/2008/7/10/328 and 
subsequent messages in this thread) and now this is happening with 
configfs. I already 2 times described you why configfs isn't appropriate 
for a SCSI target (the first time in 
http://lkml.org/lkml/2008/10/21/259), but you keep refusing to see it. 
In short:

1. Kernel can't create subdirectories in configfs

2. Sysfs doesn't allow files >4K

3. What you have been doing to live with the above limitations is 
implementing "access allowed only for explicitly specified initiators 
and forbidden for all others" security approach. This approach is 
unacceptable on practice. The majority of people simply define available 
devices for a target and don't bother with listing initiators, which 
allowed to connect to it. But you forces them to do that and keep doing 
again and again for each related network change.

In contrast, sysfs allows kernel to create subdirectories. It will allow 
to workaround the 4K limitation by a simple subdirectories hierarchy. 
So, both security approaches ("access allowed only for explicitly 
specified initiators and forbidden for all others" and "access forbidden 
only for explicitly specified initiators and allowed for all others") 
can be seamlessly implemented on sysfs as it is currently done on procfs 
in SCST.

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