linux-kernel - Re: [PATCH] sg_io: allow UNMAP and WRITE SAME without CAP_SYS

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, 11 Sep 2012 19:56:53 +0200
From:	Paolo Bonzini <pbonzini@...hat.com>
To:	Tejun Heo <tj@...nel.org>
CC:	linux-kernel@...r.kernel.org, axboe@...nel.dk,
	linux-scsi@...r.kernel.org,
	"James E.J. Bottomley" <JBottomley@...allels.com>
Subject: Re: [PATCH] sg_io: allow UNMAP and WRITE SAME without CAP_SYS_RAWIO

Il 11/09/2012 18:59, Tejun Heo ha scritto:
> FWIW, I don't think this is the right way to expose functionality
> which needs management in terms of access control, interpretation
> (stacking drivers) and serving concurrent users.  SG_IO filtering was
> mostly for cd/dvd burning and other removeable devices.

Understood; unfortunately, there is another major user of it
(virtualization).  If you are passing "raw" LUNs down to a virtual
machine, there's no possibility at all to use a properly encapsulated
interface and still be able to pass sense data etc. back to the virtual
machine.  And it's only going to grow now that people are starting to
use virtio-scsi.

The set of use cases is so variable that no single filter can accomodate
all of them: high availability people want persistent reservations, NAS
people want trim/discard, but these are just two groups.  Someone is
using a Windows VM to run vendor tools and wants to have access to
vendor-specific commands.

You can tell this last group to use root, but not everyone else who is
already relying on Unix permissions, SELinux and/or device cgroups to
confine their virtual machines.

A generic filter (see
http://article.gmane.org/gmane.linux.kernel/1312326 for a proposal)
would be satisfactory for everyone, but it's also a major undertaking
and so far I've not received a single comment about it.

> So, it wouldn't be a good idea to abuse SG_IO filtering for exposing
> trim/discard.  It's something which should be retired or at least
> severely restricted in time.  I don't think we want to be developing
> new uses of it.
> 
> I think trim/discards are fairly easy to abstract and common enough to
> justify having properly abstracted interface.  In fact, we already
> have block layer interface for it - BLKDISCARD.  If it's lacking,
> let's improve that.

I do want to improve the block layer interfaces to avoid that people use
SG_IO.  But unfortunately this is for a completely different use case.

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