linux-kernel - Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices

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]

Message-ID: <CA+55aFw+ipBQFTj9SbNjE1KkS+xNpY7RdF1emSf7WrzavyReqA@mail.gmail.com>
Date:	Thu, 22 Dec 2011 14:25:56 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Paolo Bonzini <pbonzini@...hat.com>
Cc:	linux-kernel@...r.kernel.org, security@...nel.org,
	pmatouse@...hat.com, agk@...hat.com, jbottomley@...allels.com,
	mchristi@...hat.com, msnitzer@...hat.com
Subject: Re: [PATCH 2/3] block: fail SCSI passthrough ioctls on partition devices

On Thu, Dec 22, 2011 at 2:08 PM, Paolo Bonzini <pbonzini@...hat.com> wrote:
>
> I don't know.  But given the ways in which earlier versions broke during
> testing, I wouldn't be able to tell before running many tests.  Which with
> the Christmas break would easily mean a little less than 2 weeks.

I don't think I'm ready to apply this as-is anyway, exactly because
I'd worry about some distribution really depending on being able to
eject disks by partition etc.

I don't *think* anybody does something as crazy as giving actual block
device ownership to people, but I don't know - and I could easily
imagine that even if they don't give the block device to the user, the
suid binary might do "eject /dev/sda1" etc. And one way to do that is
to do the "door unlock" scsi command itself.

So at this point I'd much *much* rather see this as a "we merge it for
3.3 and mark it for stable", so that we can at least get the testing
in the git tree, rather than me taking what could potentially break
peoples setups very late in the -rc series just before a release.

>> That's a completely independent bug that has been discussed several
>> times. We probably should just bite the bullet and fix it. EINVAL is
>> never the right return value (unless the per-ioctl arguments
>> themselves are invalid, not for bad ioctls).
>
> Makes a lot of sense and I was wondering about it myself, but I'm not sure
> stable would accept that.

Again, I think it's something we should do during the merge window
(early at that).

It really has come up several times, it just always comes up at the
wrong moment. If you remind me after the 3.2 release, I'll make sure
to "just do it", and we'll see if anything break.

I doubt anything will, because ENOTTY really is the correct error
return (to user space - for traditional reasons) for "no such ioctl".

Inside the kernel we generally want to use ENOIOCTLCMD, which is much
better named - and thus avoids the confusion that some people have
about the ENOTTY name - and that also has the whole "let's just try
another approach one then".

>> The EINVAL return comes from some people who didn't understand that
>> ENOTTY means "no such ioctl" despite the name.
>
> I did. :)

I suspect most people who have used Unix for a long time kind of take
the "ENOTTY - no such ioctl" thing for granted and don't even think
about it, but we do have a lot of people who write drivers etc and
that started with Linux, and I can understand why they think "ENOTTY"
is an odd name for a SCSI device driver to use.

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