While looking at the f_pos corruption thing, I found that splice() to
a regular file totally ignores O_APPEND. Which allows users to bypass
the append-only restriction. Bad...
The only question is how this should be solved? Should splice()
respect O_APPEND and ignore the offset? Or should it just return
-EINVAL?
Thanks,
Miklos
On Thu, 9 Oct 2008, Miklos Szeredi wrote:
>
> While looking at the f_pos corruption thing, I found that splice() to
> a regular file totally ignores O_APPEND. Which allows users to bypass
> the append-only restriction. Bad...
>
> The only question is how this should be solved? Should splice()
> respect O_APPEND and ignore the offset? Or should it just return
> -EINVAL?
Good catch. sendfile() has the same issue, but I don't think we ever did
sendpage() for any filesystems, so it won't ever be relevant, and this is
probably just a splice issue.
EINVAL seems the simplest thing. Should check S_IMMUTABLE too for that
matter. Possible patch appended.
I do wonder if we shouldn't just do this in rw_verify_area(). The whole
reason for that function is that we used to have all those flock checks
etc spread out all over, and some path would inevitably just miss one
check or another. It's kind of stupid to expect low-level filesystems to
do the IS_APPEND/IS_IMMUTABLE checks.
Comments?
Linus
---
fs/splice.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/fs/splice.c b/fs/splice.c
index 1bbc6f4..769b2d3 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -891,6 +891,7 @@ static long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
loff_t *ppos, size_t len, unsigned int flags)
{
int ret;
+ struct inode *inode;
if (unlikely(!out->f_op || !out->f_op->splice_write))
return -EINVAL;
@@ -898,6 +899,12 @@ static long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
if (unlikely(!(out->f_mode & FMODE_WRITE)))
return -EBADF;
+ inode = out->f_dentry->d_inode;
+ if (IS_IMMUTABLE(inode))
+ return -EPERM;
+ if (IS_APPEND(inode))
+ return -EINVAL;
+
ret = rw_verify_area(WRITE, out, ppos, len);
if (unlikely(ret < 0))
return ret;
On Thu, 9 Oct 2008, Linus Torvalds wrote:
> I do wonder if we shouldn't just do this in rw_verify_area(). The whole
> reason for that function is that we used to have all those flock checks
> etc spread out all over, and some path would inevitably just miss one
> check or another. It's kind of stupid to expect low-level filesystems to
> do the IS_APPEND/IS_IMMUTABLE checks.
Do we expect them? I thought we don't care if it's marked immutable
or append-only after the file has been opened, same as with normal
permissions.
> Comments?
Your patch still ignores O_APPEND, is that what we want? It sounds
sort of strange. pwrite() for example honors O_APPEND and ignores the
position, AFAICS.
Miklos
On Thu, 9 Oct 2008, Miklos Szeredi wrote:
>
> Your patch still ignores O_APPEND, is that what we want? It sounds
> sort of strange. pwrite() for example honors O_APPEND and ignores the
> position, AFAICS.
You're right. We can (and should) just check O_APPEND, because it must be
set if IS_APPEND() is set on the inode.
And yeah, IS_IMMUTABLE is checked at open too. So no worries.
And it turns out that handling O_APPEND is actually pretty easy, so
instead of doing -EINVAL, we can just implement it. Something like this
(untested, of course).
Does this look better?
Linus
---
fs/splice.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/fs/splice.c b/fs/splice.c
index 1bbc6f4..8aca87b 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1120,11 +1120,17 @@ static long do_splice(struct file *in, loff_t __user *off_in,
if (off_in)
return -ESPIPE;
if (off_out) {
+ if (out->f_flags & O_APPEND)
+ return -EINVAL;
if (out->f_op->llseek == no_llseek)
return -EINVAL;
if (copy_from_user(&offset, off_out, sizeof(loff_t)))
return -EFAULT;
off = &offset;
+ } else if (out->f_flags & O_APPEND) {
+ struct inode *inode = out->f_dentry->d_inode;
+ offset = i_size_read(inode);
+ off = &offset;
} else
off = &out->f_pos;
Miklos Szeredi <[email protected]> writes:
> pwrite() for example honors O_APPEND and ignores the position, AFAICS.
If it does, then it violates POSIX (see
<http://www.opengroup.org/austin/docs/austin_325.txt>, where the
behavior of pwrite with O_APPEND is clarified).
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Thu, 9 Oct 2008, Linus Torvalds wrote:
> And it turns out that handling O_APPEND is actually pretty easy, so
> instead of doing -EINVAL, we can just implement it. Something like this
> (untested, of course).
>
> Does this look better?
Yeah, only the append is now racy because the O_APPEND check is
outside i_mutex. So maybe just stick with -EINVAL in
do_splice_from()? That also covers do_splice_direct(), which is used
in NFS and sendfile() and a couple of other places.
We know that nobody is currently relying on O_APPEND semantics with
splice, so this should be OK.
Untested patch...
Miklos
Index: linux-2.6/fs/splice.c
===================================================================
--- linux-2.6.orig/fs/splice.c 2008-08-29 14:39:20.000000000 +0200
+++ linux-2.6/fs/splice.c 2008-10-09 18:19:25.000000000 +0200
@@ -892,6 +892,9 @@ static long do_splice_from(struct pipe_i
{
int ret;
+ if (out->f_flags & O_APPEND)
+ return -EINVAL;
+
if (unlikely(!out->f_op || !out->f_op->splice_write))
return -EINVAL;
On Thu, 09 Oct 2008, Andreas Schwab wrote:
> Miklos Szeredi <[email protected]> writes:
>
> > pwrite() for example honors O_APPEND and ignores the position, AFAICS.
>
> If it does, then it violates POSIX (see
I checked and it does. Nobody seems to care though, not even the
POSIX conformance checkers :)
Miklos
Miklos Szeredi <[email protected]> writes:
> I checked and it does. Nobody seems to care though, not even the
> POSIX conformance checkers :)
According to
<http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6655660>
they do now.
Andreas.
--
Andreas Schwab, SuSE Labs, [email protected]
SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
On Thu, 9 Oct 2008, Miklos Szeredi wrote:
>
> We know that nobody is currently relying on O_APPEND semantics with
> splice, so this should be OK.
Having now realized that apparently you can't rely on O_APPEND for
anything but plain write _anyway_ (ie pwrite shouldn't honor it), I'm
going to drop this thing as "let's think about it more".
Maybe the right thing to do is to just say that O_APPEND (and IS_APPEND)
is really not as reliable as people might expect, and just say that the
only thing it affects is a plain write() system call.
Of course, I think POSIX is crazy, and we probably _should_ always honor
O_APPEND, and returning -EINVAL is the right thing for both pwrite and
splice, but this is all a murkier issue than it looked like originally,
and any possible "security" implications are dubious in that you cannot
really depend on O_APPEND/IS_APPEND anyway.
Linus
On Thu, 9 Oct 2008, Linus Torvalds wrote:
> Of course, I think POSIX is crazy, and we probably _should_ always honor
> O_APPEND, and returning -EINVAL is the right thing for both pwrite and
> splice, but this is all a murkier issue than it looked like originally,
> and any possible "security" implications are dubious in that you cannot
> really depend on O_APPEND/IS_APPEND anyway.
The thing is, the append-only attribute is absolutely useless without
being able to depend on it. So in that sense I think the IS_APPEND
issue is important, and I'm fine with your original proposal for that
(except we don't need the IS_IMMUTABLE check).
I also agree that the O_APPEND issue is murky and should probably be
discussed separately.
Thanks,
Miklos
----
Subject: splice: disallow random writes for append-only inodes
From: Linus Torvalds <[email protected]>
It was possible to write to a random location in an append-only file
using splice.
Signed-off-by: Miklos Szeredi <[email protected]>
---
fs/splice.c | 5 +++++
1 file changed, 5 insertions(+)
Index: linux-2.6/fs/splice.c
===================================================================
--- linux-2.6.orig/fs/splice.c 2008-10-09 21:46:07.000000000 +0200
+++ linux-2.6/fs/splice.c 2008-10-09 21:47:42.000000000 +0200
@@ -891,6 +891,7 @@ static long do_splice_from(struct pipe_i
loff_t *ppos, size_t len, unsigned int flags)
{
int ret;
+ struct inode *inode;
if (unlikely(!out->f_op || !out->f_op->splice_write))
return -EINVAL;
@@ -898,6 +899,10 @@ static long do_splice_from(struct pipe_i
if (unlikely(!(out->f_mode & FMODE_WRITE)))
return -EBADF;
+ inode = out->f_dentry->d_inode;
+ if (IS_APPEND(inode))
+ return -EINVAL;
+
ret = rw_verify_area(WRITE, out, ppos, len);
if (unlikely(ret < 0))
return ret;
On Thu, 9 Oct 2008, Miklos Szeredi wrote:
>
> The thing is, the append-only attribute is absolutely useless without
> being able to depend on it. So in that sense I think the IS_APPEND
> issue is important, and I'm fine with your original proposal for that
> (except we don't need the IS_IMMUTABLE check).
Heh. In the meantime, I had grown to hate that more complex patch.
So because I do see your point with IS_APPEND (being different from
O_APPEND), but because I also think that O_APPEND itself is a gray and
murky area, I just committed the following. I doubt anybody will ever even
notice it, but while I think it's all debatable, we might as well debate
it with this in place. I do agree that it's "safer" behaviour.
Linus
---
commit a05b4085484ac45558810e4c5928e5a291c20f65
Author: Linus Torvalds <[email protected]>
Date: Thu Oct 9 14:04:54 2008 -0700
Don't allow splice() to files opened with O_APPEND
This is debatable, but while we're debating it, let's disallow the
combination of splice and an O_APPEND destination.
It's not entirely clear what the semantics of O_APPEND should be, and
POSIX apparently expects pwrite() to ignore O_APPEND, for example. So
we could make up any semantics we want, including the old ones.
But Miklos convinced me that we should at least give it some thought,
and that accepting writes at arbitrary offsets is wrong at least for
IS_APPEND() files (which always have O_APPEND set, even if the reverse
isn't true: you can obviously have O_APPEND set on a regular file).
So disallow O_APPEND entirely for now. I doubt anybody cares, and this
way we have one less gray area to worry about.
Reported-and-argued-for-by: Miklos Szeredi <[email protected]>
Cc: Jens Axboe <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
diff --git a/fs/splice.c b/fs/splice.c
index 1bbc6f4..a1e701c 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -898,6 +898,9 @@ static long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
if (unlikely(!(out->f_mode & FMODE_WRITE)))
return -EBADF;
+ if (unlikely(out->f_flags & O_APPEND))
+ return -EINVAL;
+
ret = rw_verify_area(WRITE, out, ppos, len);
if (unlikely(ret < 0))
return ret;
On Thu, Oct 09 2008, Linus Torvalds wrote:
>
>
> On Thu, 9 Oct 2008, Miklos Szeredi wrote:
> >
> > The thing is, the append-only attribute is absolutely useless without
> > being able to depend on it. So in that sense I think the IS_APPEND
> > issue is important, and I'm fine with your original proposal for that
> > (except we don't need the IS_IMMUTABLE check).
>
> Heh. In the meantime, I had grown to hate that more complex patch.
>
> So because I do see your point with IS_APPEND (being different from
> O_APPEND), but because I also think that O_APPEND itself is a gray and
> murky area, I just committed the following. I doubt anybody will ever even
> notice it, but while I think it's all debatable, we might as well debate
> it with this in place. I do agree that it's "safer" behaviour.
>
> Linus
>
> ---
> commit a05b4085484ac45558810e4c5928e5a291c20f65
> Author: Linus Torvalds <[email protected]>
> Date: Thu Oct 9 14:04:54 2008 -0700
>
> Don't allow splice() to files opened with O_APPEND
>
> This is debatable, but while we're debating it, let's disallow the
> combination of splice and an O_APPEND destination.
>
> It's not entirely clear what the semantics of O_APPEND should be, and
> POSIX apparently expects pwrite() to ignore O_APPEND, for example. So
> we could make up any semantics we want, including the old ones.
>
> But Miklos convinced me that we should at least give it some thought,
> and that accepting writes at arbitrary offsets is wrong at least for
> IS_APPEND() files (which always have O_APPEND set, even if the reverse
> isn't true: you can obviously have O_APPEND set on a regular file).
>
> So disallow O_APPEND entirely for now. I doubt anybody cares, and this
> way we have one less gray area to worry about.
>
> Reported-and-argued-for-by: Miklos Szeredi <[email protected]>
> Cc: Jens Axboe <[email protected]>
> Signed-off-by: Linus Torvalds <[email protected]>
A little late I see, but FWIW I agree. I doubt that anyone uses splice
with O_APPEND anyways, so should be zero-impact on that account at
least.
>
> diff --git a/fs/splice.c b/fs/splice.c
> index 1bbc6f4..a1e701c 100644
> --- a/fs/splice.c
> +++ b/fs/splice.c
> @@ -898,6 +898,9 @@ static long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
> if (unlikely(!(out->f_mode & FMODE_WRITE)))
> return -EBADF;
>
> + if (unlikely(out->f_flags & O_APPEND))
> + return -EINVAL;
> +
> ret = rw_verify_area(WRITE, out, ppos, len);
> if (unlikely(ret < 0))
> return ret;
--
Jens Axboe
On Thu, 9 Oct 2008, Jens Axboe wrote:
>
> A little late I see, but FWIW I agree.
Well, not too late, since I hadn't pushed it out. I amended the commit to
have an acked-by from you.
And now it _is_ pushed out.
Linus
On Thu, 9 Oct 2008, Linus Torvalds wrote:
> On Thu, 9 Oct 2008, Miklos Szeredi wrote:
> >
> > The thing is, the append-only attribute is absolutely useless without
> > being able to depend on it. So in that sense I think the IS_APPEND
> > issue is important, and I'm fine with your original proposal for that
> > (except we don't need the IS_IMMUTABLE check).
>
> Heh. In the meantime, I had grown to hate that more complex patch.
>
> So because I do see your point with IS_APPEND (being different from
> O_APPEND), but because I also think that O_APPEND itself is a gray and
> murky area, I just committed the following. I doubt anybody will ever even
> notice it, but while I think it's all debatable, we might as well debate
> it with this in place. I do agree that it's "safer" behaviour.
Thanks.
I suspect this qualifies for stable kernels too. Stable team, can you
please add this to your queue?
The final commit is:
commit efc968d450e013049a662d22727cf132618dcb2f
Author: Linus Torvalds <[email protected]>
Date: Thu Oct 9 14:04:54 2008 -0700
Don't allow splice() to files opened with O_APPEND
This is debatable, but while we're debating it, let's disallow the
combination of splice and an O_APPEND destination.
It's not entirely clear what the semantics of O_APPEND should be, and
POSIX apparently expects pwrite() to ignore O_APPEND, for example. So
we could make up any semantics we want, including the old ones.
But Miklos convinced me that we should at least give it some thought,
and that accepting writes at arbitrary offsets is wrong at least for
IS_APPEND() files (which always have O_APPEND set, even if the reverse
isn't true: you can obviously have O_APPEND set on a regular file).
So disallow O_APPEND entirely for now. I doubt anybody cares, and this
way we have one less gray area to worry about.
Reported-and-argued-for-by: Miklos Szeredi <[email protected]>
Acked-by: Jens Axboe <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
diff --git a/fs/splice.c b/fs/splice.c
index 1bbc6f4..a1e701c 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -898,6 +898,9 @@ static long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
if (unlikely(!(out->f_mode & FMODE_WRITE)))
return -EBADF;
+ if (unlikely(out->f_flags & O_APPEND))
+ return -EINVAL;
+
ret = rw_verify_area(WRITE, out, ppos, len);
if (unlikely(ret < 0))
return ret;
On Fri, Oct 10 2008, Miklos Szeredi wrote:
> On Thu, 9 Oct 2008, Linus Torvalds wrote:
> > On Thu, 9 Oct 2008, Miklos Szeredi wrote:
> > >
> > > The thing is, the append-only attribute is absolutely useless without
> > > being able to depend on it. So in that sense I think the IS_APPEND
> > > issue is important, and I'm fine with your original proposal for that
> > > (except we don't need the IS_IMMUTABLE check).
> >
> > Heh. In the meantime, I had grown to hate that more complex patch.
> >
> > So because I do see your point with IS_APPEND (being different from
> > O_APPEND), but because I also think that O_APPEND itself is a gray and
> > murky area, I just committed the following. I doubt anybody will ever even
> > notice it, but while I think it's all debatable, we might as well debate
> > it with this in place. I do agree that it's "safer" behaviour.
>
> Thanks.
>
> I suspect this qualifies for stable kernels too. Stable team, can you
> please add this to your queue?
>
> The final commit is:
>
> commit efc968d450e013049a662d22727cf132618dcb2f
> Author: Linus Torvalds <[email protected]>
> Date: Thu Oct 9 14:04:54 2008 -0700
>
> Don't allow splice() to files opened with O_APPEND
>
> This is debatable, but while we're debating it, let's disallow the
> combination of splice and an O_APPEND destination.
>
> It's not entirely clear what the semantics of O_APPEND should be, and
> POSIX apparently expects pwrite() to ignore O_APPEND, for example. So
> we could make up any semantics we want, including the old ones.
>
> But Miklos convinced me that we should at least give it some thought,
> and that accepting writes at arbitrary offsets is wrong at least for
> IS_APPEND() files (which always have O_APPEND set, even if the reverse
> isn't true: you can obviously have O_APPEND set on a regular file).
>
> So disallow O_APPEND entirely for now. I doubt anybody cares, and this
> way we have one less gray area to worry about.
>
> Reported-and-argued-for-by: Miklos Szeredi <[email protected]>
> Acked-by: Jens Axboe <[email protected]>
And lets then change this to <[email protected]>
:-)
> Signed-off-by: Linus Torvalds <[email protected]>
>
> diff --git a/fs/splice.c b/fs/splice.c
> index 1bbc6f4..a1e701c 100644
> --- a/fs/splice.c
> +++ b/fs/splice.c
> @@ -898,6 +898,9 @@ static long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
> if (unlikely(!(out->f_mode & FMODE_WRITE)))
> return -EBADF;
>
> + if (unlikely(out->f_flags & O_APPEND))
> + return -EINVAL;
> +
> ret = rw_verify_area(WRITE, out, ppos, len);
> if (unlikely(ret < 0))
> return ret;
--
Jens Axboe
Hey Linus,
On Thu, Oct 9, 2008 at 11:14 PM, Linus Torvalds
<[email protected]> wrote:
>
>
> On Thu, 9 Oct 2008, Miklos Szeredi wrote:
>>
>> The thing is, the append-only attribute is absolutely useless without
>> being able to depend on it. So in that sense I think the IS_APPEND
>> issue is important, and I'm fine with your original proposal for that
>> (except we don't need the IS_IMMUTABLE check).
>
> Heh. In the meantime, I had grown to hate that more complex patch.
>
> So because I do see your point with IS_APPEND (being different from
> O_APPEND), but because I also think that O_APPEND itself is a gray and
> murky area, I just committed the following. I doubt anybody will ever even
> notice it, but while I think it's all debatable, we might as well debate
> it with this in place. I do agree that it's "safer" behaviour.
Please do CC linux-api@vger (and if you are kind, me, in case
something needs to go into man-pages) on interface changes.
Cheers,
Michael
> ---
> commit a05b4085484ac45558810e4c5928e5a291c20f65
> Author: Linus Torvalds <[email protected]>
> Date: Thu Oct 9 14:04:54 2008 -0700
>
> Don't allow splice() to files opened with O_APPEND
>
> This is debatable, but while we're debating it, let's disallow the
> combination of splice and an O_APPEND destination.
>
> It's not entirely clear what the semantics of O_APPEND should be, and
> POSIX apparently expects pwrite() to ignore O_APPEND, for example. So
> we could make up any semantics we want, including the old ones.
>
> But Miklos convinced me that we should at least give it some thought,
> and that accepting writes at arbitrary offsets is wrong at least for
> IS_APPEND() files (which always have O_APPEND set, even if the reverse
> isn't true: you can obviously have O_APPEND set on a regular file).
>
> So disallow O_APPEND entirely for now. I doubt anybody cares, and this
> way we have one less gray area to worry about.
>
> Reported-and-argued-for-by: Miklos Szeredi <[email protected]>
> Cc: Jens Axboe <[email protected]>
> Signed-off-by: Linus Torvalds <[email protected]>
>
> diff --git a/fs/splice.c b/fs/splice.c
> index 1bbc6f4..a1e701c 100644
> --- a/fs/splice.c
> +++ b/fs/splice.c
> @@ -898,6 +898,9 @@ static long do_splice_from(struct pipe_inode_info *pipe, struct file *out,
> if (unlikely(!(out->f_mode & FMODE_WRITE)))
> return -EBADF;
>
> + if (unlikely(out->f_flags & O_APPEND))
> + return -EINVAL;
> +
> ret = rw_verify_area(WRITE, out, ppos, len);
> if (unlikely(ret < 0))
> return ret;
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/ Found a documentation bug?
http://www.kernel.org/doc/man-pages/reporting_bugs.html
On Fri, Oct 10, 2008 at 11:46:00AM +0200, Miklos Szeredi wrote:
> On Thu, 9 Oct 2008, Linus Torvalds wrote:
> > On Thu, 9 Oct 2008, Miklos Szeredi wrote:
> > >
> > > The thing is, the append-only attribute is absolutely useless without
> > > being able to depend on it. So in that sense I think the IS_APPEND
> > > issue is important, and I'm fine with your original proposal for that
> > > (except we don't need the IS_IMMUTABLE check).
> >
> > Heh. In the meantime, I had grown to hate that more complex patch.
> >
> > So because I do see your point with IS_APPEND (being different from
> > O_APPEND), but because I also think that O_APPEND itself is a gray and
> > murky area, I just committed the following. I doubt anybody will ever even
> > notice it, but while I think it's all debatable, we might as well debate
> > it with this in place. I do agree that it's "safer" behaviour.
>
> Thanks.
>
> I suspect this qualifies for stable kernels too. Stable team, can you
> please add this to your queue?
Queue for which kernel releases? .25, .26, and/or .27?
thanks,
greg k-h
On Fri, 10 Oct 2008, Greg KH wrote:
> On Fri, Oct 10, 2008 at 11:46:00AM +0200, Miklos Szeredi wrote:
> > I suspect this qualifies for stable kernels too. Stable team, can you
> > please add this to your queue?
>
> Queue for which kernel releases? .25, .26, and/or .27?
25 and 26. It's in .27.
Thanks,
Miklos
On Fri, Oct 10, 2008 at 06:05:48PM +0200, Miklos Szeredi wrote:
> On Fri, 10 Oct 2008, Greg KH wrote:
> > On Fri, Oct 10, 2008 at 11:46:00AM +0200, Miklos Szeredi wrote:
> > > I suspect this qualifies for stable kernels too. Stable team, can you
> > > please add this to your queue?
> >
> > Queue for which kernel releases? .25, .26, and/or .27?
>
> 25 and 26. It's in .27.
Ah, thanks, will queue it up.
greg k-h