On Tuesday 25 January 2005 17:21, you wrote:
: > : The command restriction table _only_ works through the SG_IO path, which
: > : does include CDROM_SEND_PACKET as well since it is layered on top of
: > : SG_IO. It doesn't control various driver ioctl exported interfaces, they
: > : would need to a
On Tue, Jan 25 2005, Elias da Silva wrote:
> On Tuesday 25 January 2005 13:45, you wrote:
> [snip]
> : If I'm not mistaken, Peter Jones has posted a few iterations of such an
> : fs some months ago.
>
> Thank you. I will check this...
>
> : > Do we have a clear understanding that this fs would on
On Tuesday 25 January 2005 13:45, you wrote:
[snip]
: If I'm not mistaken, Peter Jones has posted a few iterations of such an
: fs some months ago.
Thank you. I will check this...
: > Do we have a clear understanding that this fs would only
: > be a benefit if *All* the different ways to access t
On Tuesday 25 January 2005 13:44, you wrote:
: On Maw, 2005-01-25 at 09:29, Elias da Silva wrote:
: > On Tuesday 25 January 2005 01:01, you wrote:
: > Yes, sometimes you have to risk broken software in favor of augmented
: > security, but so far we only have broken software.
:
: Well let me see in
On Maw, 2005-01-25 at 09:29, Elias da Silva wrote:
> On Tuesday 25 January 2005 01:01, you wrote:
> Yes, sometimes you have to risk broken software in favor of augmented
> security, but so far we only have broken software.
Well let me see in 2.6.5 if you could read open the block device at all
you
On Tue, Jan 25 2005, Elias da Silva wrote:
> : Someone did actually have a demo of a small fs that allowed you to
> : fiddle with the status but possibly the code could get smarter for
> : "exclusive user of media". I'm not sure if that is worth it.
>
> Do you have the name of the fs and/or the na
On Tuesday 25 January 2005 01:01, you wrote:
[snip]
: > This is exactly the point: if the kernel wants to be safe, the
: > authentication procedure should be totally implemented in the kernel
: > and be protected against further changes via "alternative" ways...
: > but it isn't now and probably wo
On Tue, Jan 25 2005, Alan Cox wrote:
> Someone did actually have a demo of a small fs that allowed you to
> fiddle with the status but possibly the code could get smarter for
> "exclusive user of media". I'm not sure if that is worth it.
I think it is worth it, on the grounds that this is a never
On Llu, 2005-01-24 at 22:10, Elias da Silva wrote:
> This is exactly the point: if the kernel wants to be safe, the
> authentication procedure should be totally implemented in the kernel
> and be protected against further changes via "alternative" ways...
> but it isn't now and probably won't be al
On Monday 24 January 2005 21:39, you wrote:
[snip]
: > This is true for protected media because of the authentication
: > process needed between "host" and DVD device. IMHO,
: > the classification of the opcodes
: >
: > a. GPCMD_SEND_KEY and
: > b. GPCMD_SET_STREAMING
: >
: > as onl
On Mon, Jan 24 2005, Elias da Silva wrote:
> > On Sat, Jan 22 2005, Elias da Silva wrote:
> > > Attached patch fixes a problem of reading Video DVDs
> > > through the cdrom_ioctl interface. VMware is among
> > > the prominent victims.
> > >
> > > The bug was introduced in kernel version 2.6.8 in t
> On Sat, Jan 22 2005, Elias da Silva wrote:
> > Attached patch fixes a problem of reading Video DVDs
> > through the cdrom_ioctl interface. VMware is among
> > the prominent victims.
> >
> > The bug was introduced in kernel version 2.6.8 in the
> > function verify_command().
>
> It's not a bug,
On Sat, Jan 22 2005, Elias da Silva wrote:
> Moin.
>
> Attached patch fixes a problem of reading Video DVDs
> through the cdrom_ioctl interface. VMware is among
> the prominent victims.
>
> The bug was introduced in kernel version 2.6.8 in the
> function verify_command().
It's not a bug, add wri
13 matches
Mail list logo
