Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1220465 > unrolled thread

Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] kernel/sysctl.c: If "count" including the terminating  byte '\0' the write system call should retrun success. Sean Fu <fxinrong@gmail.com> - 2015-09-08 05:20 +0200
    Re: [PATCH] kernel/sysctl.c: If "count" including the terminating  byte '\0' the write system call should retrun success. Steven Rostedt <rostedt@goodmis.org> - 2015-09-08 17:20 +0200
      Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success. ebiederm@xmission.com (Eric W. Biederman) - 2015-09-08 18:30 +0200
        Re: [PATCH] kernel/sysctl.c: If "count" including the terminating  byte '\0' the write system call should retrun success. Steven Rostedt <rostedt@goodmis.org> - 2015-09-08 18:40 +0200
          Re: [PATCH] kernel/sysctl.c: If "count" including the terminating  byte '\0' the write system call should retrun success. Sean Fu <fxinrong@gmail.com> - 2015-09-11 11:10 +0200
            Re: [PATCH] kernel/sysctl.c: If "count" including the terminating  byte '\0' the write system call should retrun success. Steven Rostedt <rostedt@goodmis.org> - 2015-09-11 15:50 +0200
            Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success. ebiederm@xmission.com (Eric W. Biederman) - 2015-09-11 19:10 +0200
              Re: [PATCH] kernel/sysctl.c: If "count" including the terminating  byte '\0' the write system call should retrun success. Sean Fu <fxinrong@gmail.com> - 2015-09-13 14:40 +0200
                Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success. ebiederm@xmission.com (Eric W. Biederman) - 2015-09-13 19:00 +0200
                  Re: [PATCH] kernel/sysctl.c: If "count" including the terminating  byte '\0' the write system call should retrun success. Sean Fu <fxinrong@gmail.com> - 2015-09-15 11:40 +0200
                    Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success. "Eric W. Biederman" <ebiederm@xmission.com> - 2015-09-15 16:20 +0200
                Re: [PATCH] kernel/sysctl.c: If "count" including the terminating  byte '\0' the write system call should retrun success. Steven Rostedt <rostedt@goodmis.org> - 2015-09-13 22:10 +0200
                  Re: [PATCH] kernel/sysctl.c: If "count" including the terminating  byte '\0' the write system call should retrun success. Sean Fu <fxinrong@gmail.com> - 2015-09-15 11:40 +0200
                    Re: [PATCH] kernel/sysctl.c: If "count" including the terminating  byte '\0' the write system call should retrun success. Steven Rostedt <rostedt@goodmis.org> - 2015-09-15 16:00 +0200

#1220465 — Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.

On Fri, Aug 28, 2015 at 11:31 AM, Sean Fu <fxinrong@gmail.com> wrote:
> On Thu, Aug 27, 2015 at 4:32 PM, Sean Fu <fxinrong@gmail.com> wrote:
>> On Thu, Aug 27, 2015 at 10:32 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>>> On Thu, 27 Aug 2015 08:17:29 +0800
>>> Sean Fu <fxinrong@gmail.com> wrote:
>>>> strace execute result:
>>>> write(3, "1\2\0", 3)                    = -1 EINVAL (Invalid argument)
> If vleft > 1, "1\0 2" is treated as invalid paraments and all string
> include '\0' will be invalid.
Hi All experts,
Could you please signed off this patch?
>
>>>>
>>>> >
>>>> > -- Steve
>>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1220922

On Tue, 8 Sep 2015 11:11:38 +0800
Sean Fu <fxinrong@gmail.com> wrote:

> On Fri, Aug 28, 2015 at 11:31 AM, Sean Fu <fxinrong@gmail.com> wrote:
> > On Thu, Aug 27, 2015 at 4:32 PM, Sean Fu <fxinrong@gmail.com> wrote:
> >> On Thu, Aug 27, 2015 at 10:32 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> >>> On Thu, 27 Aug 2015 08:17:29 +0800
> >>> Sean Fu <fxinrong@gmail.com> wrote:
> >>>> strace execute result:
> >>>> write(3, "1\2\0", 3)                    = -1 EINVAL (Invalid argument)
> > If vleft > 1, "1\0 2" is treated as invalid paraments and all string
> > include '\0' will be invalid.
> Hi All experts,
> Could you please signed off this patch?

If anyone should take this, it would be Andrew.

I have no issue with the patch. Eric, you had some issue, but I don't
see a scenario that would depend on the current behavior. That is, what
do you think would break if we put it back to the old behavior?

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1220967 — Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.

Steven Rostedt <rostedt@goodmis.org> writes:

> On Tue, 8 Sep 2015 11:11:38 +0800
> Sean Fu <fxinrong@gmail.com> wrote:
>
>> On Fri, Aug 28, 2015 at 11:31 AM, Sean Fu <fxinrong@gmail.com> wrote:
>> > On Thu, Aug 27, 2015 at 4:32 PM, Sean Fu <fxinrong@gmail.com> wrote:
>> >> On Thu, Aug 27, 2015 at 10:32 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>> >>> On Thu, 27 Aug 2015 08:17:29 +0800
>> >>> Sean Fu <fxinrong@gmail.com> wrote:
>> >>>> strace execute result:
>> >>>> write(3, "1\2\0", 3)                    = -1 EINVAL (Invalid argument)
>> > If vleft > 1, "1\0 2" is treated as invalid paraments and all string
>> > include '\0' will be invalid.
>> Hi All experts,
>> Could you please signed off this patch?
>
> If anyone should take this, it would be Andrew.
>
> I have no issue with the patch. Eric, you had some issue, but I don't
> see a scenario that would depend on the current behavior. That is, what
> do you think would break if we put it back to the old behavior?

This patch does not implement the old behavior.

The old code does use '\0' as a buffer terminator, and because it does
not check things closely I can see how it could accept a '\0' from
userspace and treat that as an early buffer terminator.

The patch treats '\0' as a number separator and allows things that have
never been allowed before and quite frankly is very scary as it just
invites bugs.

So I do not think we should merge the given patch.  It is just wrong.
One that simply truncates the input buffer at the first '\0' character I
think we can consider, although I am not a fan.

Steve as far as what I think would break.  I don't think the current
behavior should have broken anything and apparently it did.  I don't see
what a change that simply truncates the buffer at the first embedded
'\0' would break, but I don't know how to test that there isn't anything
that it will.  We are way past the point of reasonable expectations
being able to guide us.  4 years should have been more than enough soak
time to have been able to say that the change was good, but apparently
it was not.

My gut feel says that if we are going to change this, at this late date,
we find the one specific proc file that matters and change it just for
that one proc file, and in that change we treat '\0' as a terminator not
as a separator.  I never did see in the conversation which proc file it
is that actually matters.  The principle is that the more precise and
the more localized such a change is the less chance it has of causing a
regression of something else, and the greater the chance we can look at
a specific issue.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1220971

On Tue, 08 Sep 2015 11:19:14 -0500
ebiederm@xmission.com (Eric W. Biederman) wrote:


> This patch does not implement the old behavior.
> 
> The old code does use '\0' as a buffer terminator, and because it does
> not check things closely I can see how it could accept a '\0' from
> userspace and treat that as an early buffer terminator.
> 
> The patch treats '\0' as a number separator and allows things that have
> never been allowed before and quite frankly is very scary as it just
> invites bugs.
> 
> So I do not think we should merge the given patch.  It is just wrong.
> One that simply truncates the input buffer at the first '\0' character I
> think we can consider, although I am not a fan.

I agree, and was thinking this patch did that, but I didn't look close
enough (why I never gave a Reviewed-by to it either).


> 
> Steve as far as what I think would break.  I don't think the current
> behavior should have broken anything and apparently it did.  I don't see
> what a change that simply truncates the buffer at the first embedded
> '\0' would break, but I don't know how to test that there isn't anything
> that it will.  We are way past the point of reasonable expectations
> being able to guide us.  4 years should have been more than enough soak
> time to have been able to say that the change was good, but apparently
> it was not.

Well, to be fair, a lot of people (distros, etc) do not use the most
recent kernels. 4 years may be the first time a tool touches a kernel.

> 
> My gut feel says that if we are going to change this, at this late date,
> we find the one specific proc file that matters and change it just for
> that one proc file, and in that change we treat '\0' as a terminator not
> as a separator.  I never did see in the conversation which proc file it
> is that actually matters.  The principle is that the more precise and
> the more localized such a change is the less chance it has of causing a
> regression of something else, and the greater the chance we can look at
> a specific issue.

Sounds like a reasonable compromise. Sean, can you make a patch that
only affects the one proc file (comment it well in the code), and have
it accept nothing past the '\0'. Even if someone passed in "1 \0 2", it
would only see "1 "

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222639

On Wed, Sep 9, 2015 at 12:36 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Tue, 08 Sep 2015 11:19:14 -0500
> ebiederm@xmission.com (Eric W. Biederman) wrote:
>
>
>> This patch does not implement the old behavior.
>>
>> The old code does use '\0' as a buffer terminator, and because it does
>> not check things closely I can see how it could accept a '\0' from
>> userspace and treat that as an early buffer terminator.
>>
>> The patch treats '\0' as a number separator and allows things that have
>> never been allowed before and quite frankly is very scary as it just
>> invites bugs.
>>
>> So I do not think we should merge the given patch.  It is just wrong.
>> One that simply truncates the input buffer at the first '\0' character I
>> think we can consider, although I am not a fan.
>
> I agree, and was thinking this patch did that, but I didn't look close
> enough (why I never gave a Reviewed-by to it either).
>
>
>>
>> Steve as far as what I think would break.  I don't think the current
>> behavior should have broken anything and apparently it did.  I don't see
>> what a change that simply truncates the buffer at the first embedded
>> '\0' would break, but I don't know how to test that there isn't anything
>> that it will.  We are way past the point of reasonable expectations
>> being able to guide us.  4 years should have been more than enough soak
>> time to have been able to say that the change was good, but apparently
>> it was not.
>
> Well, to be fair, a lot of people (distros, etc) do not use the most
> recent kernels. 4 years may be the first time a tool touches a kernel.
>
>>
>> My gut feel says that if we are going to change this, at this late date,
>> we find the one specific proc file that matters and change it just for
>> that one proc file, and in that change we treat '\0' as a terminator not
>> as a separator.  I never did see in the conversation which proc file it
>> is that actually matters.  The principle is that the more precise and
>> the more localized such a change is the less chance it has of causing a
>> regression of something else, and the greater the chance we can look at
>> a specific issue.
>
> Sounds like a reasonable compromise. Sean, can you make a patch that
> only affects the one proc file (comment it well in the code), and have
> it accept nothing past the '\0'. Even if someone passed in "1 \0 2", it
> would only see "1 "
The current code uses uniform handler (e.g. "proc_dointvec") for all
same type proc file.
So all integer type proc file are affected.
In fact, The behavior of all integer type proc file should be changed.
>
> -- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222853

On Fri, 11 Sep 2015 17:05:31 +0800
Sean Fu <fxinrong@gmail.com> wrote:


> > Sounds like a reasonable compromise. Sean, can you make a patch that
> > only affects the one proc file (comment it well in the code), and have
> > it accept nothing past the '\0'. Even if someone passed in "1 \0 2", it
> > would only see "1 "

> The current code uses uniform handler (e.g. "proc_dointvec") for all
> same type proc file.
> So all integer type proc file are affected.
> In fact, The behavior of all integer type proc file should be changed.


Then at least make it where the \0 is the terminating string. Nothing
after it will be seen by the rest of the code in the kernel.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1222991 — Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.

Sean Fu <fxinrong@gmail.com> writes:

>> Sounds like a reasonable compromise. Sean, can you make a patch that
>> only affects the one proc file (comment it well in the code), and have
>> it accept nothing past the '\0'. Even if someone passed in "1 \0 2", it
>> would only see "1 "
> The current code uses uniform handler (e.g. "proc_dointvec") for all
> same type proc file.
> So all integer type proc file are affected.

No.  I do not believe the proprietary binary application you are dealing
with writes to all proc files that use the proc_dointvec handler.

> In fact, The behavior of all integer type proc file should be changed.

Not at all.  The only files that we can possibly justify changing today
are the files where an actual regression is being observed.

Because quite frankly 5 years is way too long to wait to report a
regression.  By and large software is reasonable and treats proc
files as text files where '\0' is an invalid character.

Accepting a '\0' is not at all reasonable for a text interface.  The
application that does it is buggy.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223654

On Sat, Sep 12, 2015 at 1:01 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Sean Fu <fxinrong@gmail.com> writes:
>
>>> Sounds like a reasonable compromise. Sean, can you make a patch that
>>> only affects the one proc file (comment it well in the code), and have
>>> it accept nothing past the '\0'. Even if someone passed in "1 \0 2", it
>>> would only see "1 "
>> The current code uses uniform handler (e.g. "proc_dointvec") for all
>> same type proc file.
>> So all integer type proc file are affected.
>
> No.  I do not believe the proprietary binary application you are dealing
> with writes to all proc files that use the proc_dointvec handler.
I means all ctl_table whose .proc_handler is "proc_dointvec" are affected.
>
>> In fact, The behavior of all integer type proc file should be changed.
>
> Not at all.  The only files that we can possibly justify changing today
> are the files where an actual regression is being observed.
>
> Because quite frankly 5 years is way too long to wait to report a
> regression.  By and large software is reasonable and treats proc
> files as text files where '\0' is an invalid character.
5 years is not enough long for distros, specially enterprise distros.
The most of HuaWei machines run our SLES10sp3(2.6.16, SUSE LINUX
ENTERPRISE SERVER).
They use one enterprise version for 5+ years usually.
>
> Accepting a '\0' is not at all reasonable for a text interface.  The
> application that does it is buggy.
It is hard to comprehend that the current kernel can accept  two bytes
"1 ", "1\t", "1\n" except "1\0".
>
> Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223723 — Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.

Sean Fu <fxinrong@gmail.com> writes:

> On Sat, Sep 12, 2015 at 1:01 AM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>> Sean Fu <fxinrong@gmail.com> writes:
>>
>>>> Sounds like a reasonable compromise. Sean, can you make a patch that
>>>> only affects the one proc file (comment it well in the code), and have
>>>> it accept nothing past the '\0'. Even if someone passed in "1 \0 2", it
>>>> would only see "1 "
>>> The current code uses uniform handler (e.g. "proc_dointvec") for all
>>> same type proc file.
>>> So all integer type proc file are affected.
>>
>> No.  I do not believe the proprietary binary application you are dealing
>> with writes to all proc files that use the proc_dointvec handler.
> I means all ctl_table whose .proc_handler is "proc_dointvec" are
> affected.

I mean this only deserves consideration because this is a regression
report.

I mean by limiting this to only the proc files that are written to by
the weird program that broke we can minimize the chances that anything
else will break.

I do not believe that the weird program that broke writes to every proc
file.  Certainly I have not heard that asserted.

>>> In fact, The behavior of all integer type proc file should be changed.
>>
>> Not at all.  The only files that we can possibly justify changing today
>> are the files where an actual regression is being observed.
>>
>> Because quite frankly 5 years is way too long to wait to report a
>> regression.  By and large software is reasonable and treats proc
>> files as text files where '\0' is an invalid character.
> 5 years is not enough long for distros, specially enterprise distros.
> The most of HuaWei machines run our SLES10sp3(2.6.16, SUSE LINUX
> ENTERPRISE SERVER).
> They use one enterprise version for 5+ years usually.

If you want to play by enterprise kernel rules please talk to your
enterprise kernel support people.

>> Accepting a '\0' is not at all reasonable for a text interface.  The
>> application that does it is buggy.
> It is hard to comprehend that the current kernel can accept  two bytes
> "1 ", "1\t", "1\n" except "1\0".

'\0' is not and has never been valid in a text file.
proc files are a text interface.
Expecting '\0' to be accepted is very strange, and apparently there is
only one program in existence that does.

That a trailing '\0' was ever accepted was due to a bug in the code.

Accepting '\0' in general in a text interface is a very dangerous and
buggy pattern so it must be done very carefully or else other
regressions or bugs could be easily introduced.

That no one has complained about this in the 5 years since the change happened
strongly indicates this no one else cares.

A very targeted very narrow regression fix that only handles a trailing
'\0' and that only changes the behavior of proc files that matter is
reasonable.

Or do you volunteer to go out and test every program that has been
written or updated to write to proc in the last 5 years (since the
behavior changed) and verify that none of them in no circumstances
depend upon failing if an trailing '\0' is included?   If you can audit
all of the code written in the last 5 years and verify that the change
will not introduce problems for any other user space program we can talk
about changing all of the proc files that use proc_dointvec.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224916

On Mon, Sep 14, 2015 at 12:44 AM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Sean Fu <fxinrong@gmail.com> writes:
>
>> On Sat, Sep 12, 2015 at 1:01 AM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>> Sean Fu <fxinrong@gmail.com> writes:
> '\0' is not and has never been valid in a text file.
> proc files are a text interface.
> Expecting '\0' to be accepted is very strange, and apparently there is
> only one program in existence that does.
>
> That a trailing '\0' was ever accepted was due to a bug in the code.
>
> Accepting '\0' in general in a text interface is a very dangerous and
> buggy pattern so it must be done very carefully or else other
> regressions or bugs could be easily introduced.
Ok,
Could you please give me more detail about the potential risk from the patch?
What is the different behavior between the patch and old kernel?
It seems like entirely same.

> Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225161 — Re: [PATCH] kernel/sysctl.c: If "count" including the terminating byte '\0' the write system call should retrun success.

On September 15, 2015 4:30:56 AM CDT, Sean Fu <fxinrong@gmail.com> wrote:
>On Mon, Sep 14, 2015 at 12:44 AM, Eric W. Biederman
><ebiederm@xmission.com> wrote:
>> Sean Fu <fxinrong@gmail.com> writes:
>>
>>> On Sat, Sep 12, 2015 at 1:01 AM, Eric W. Biederman
>>> <ebiederm@xmission.com> wrote:
>>>> Sean Fu <fxinrong@gmail.com> writes:
>> '\0' is not and has never been valid in a text file.
>> proc files are a text interface.
>> Expecting '\0' to be accepted is very strange, and apparently there
>is
>> only one program in existence that does.
>>
>> That a trailing '\0' was ever accepted was due to a bug in the code.
>>
>> Accepting '\0' in general in a text interface is a very dangerous and
>> buggy pattern so it must be done very carefully or else other
>> regressions or bugs could be easily introduced.
>Ok,
>Could you please give me more detail about the potential risk from the
>patch?

Regressions.  AKA There may now be programs that depend on writing a  '\0' failing.

>What is the different behavior between the patch and old kernel?
>It seems like entirely same.

Not at all.  And clear explanations have already been given.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1223744

On Sun, 13 Sep 2015 20:39:31 +0800
Sean Fu <fxinrong@gmail.com> wrote:


> > Accepting a '\0' is not at all reasonable for a text interface.  The
> > application that does it is buggy.
> It is hard to comprehend that the current kernel can accept  two bytes
> "1 ", "1\t", "1\n" except "1\0".

Um, it does not seem hard to comprehend at all. As this is a string,
and it acts the same as a printf() or strlen.

	strlen("1 ") == 2
	strlen("1\t") == 2
	strlen("1\n") == 2
	strlen("1\0") == 1

Big difference to me.

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224896

According to POSIX standard,  "The write() function shall attempt to
write nbyte bytes from the buffer pointed to by buf to the file
associated with the open file descriptor, fildes.".
So it is not the length of string(strlen).

On Mon, Sep 14, 2015 at 4:05 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Sun, 13 Sep 2015 20:39:31 +0800
> Sean Fu <fxinrong@gmail.com> wrote:
>
>
>> > Accepting a '\0' is not at all reasonable for a text interface.  The
>> > application that does it is buggy.
>> It is hard to comprehend that the current kernel can accept  two bytes
>> "1 ", "1\t", "1\n" except "1\0".
>
> Um, it does not seem hard to comprehend at all. As this is a string,
> and it acts the same as a printf() or strlen.
>
>         strlen("1 ") == 2
>         strlen("1\t") == 2
>         strlen("1\n") == 2
>         strlen("1\0") == 1
>
> Big difference to me.
>
> -- Steve
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225132

On Tue, 15 Sep 2015 17:10:11 +0800
Sean Fu <fxinrong@gmail.com> wrote:

> According to POSIX standard,  "The write() function shall attempt to
> write nbyte bytes from the buffer pointed to by buf to the file
> associated with the open file descriptor, fildes.".
> So it is not the length of string(strlen).

Why do we care about the "write()" function? Yeah, so be it. Send
out as much data as you want. We care about the effects of the proc file
system by the input it receives. You can send in X amounts of data.
That's not broken. The only apps that would send out a string to the
proc filesystem that includes "\0" and beyond is root kits. I'm sorry
but your arguments are starting to go south. I'm starting to think that
the app that broke is a root kit, and maybe it's best to just Nack this.

-- Steve


> 
> On Mon, Sep 14, 2015 at 4:05 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Sun, 13 Sep 2015 20:39:31 +0800
> > Sean Fu <fxinrong@gmail.com> wrote:
> >
> >
> >> > Accepting a '\0' is not at all reasonable for a text interface.  The
> >> > application that does it is buggy.
> >> It is hard to comprehend that the current kernel can accept  two bytes
> >> "1 ", "1\t", "1\n" except "1\0".
> >
> > Um, it does not seem hard to comprehend at all. As this is a string,
> > and it acts the same as a printf() or strlen.
> >
> >         strlen("1 ") == 2
> >         strlen("1\t") == 2
> >         strlen("1\n") == 2
> >         strlen("1\0") == 1
> >
> > Big difference to me.
> >
> > -- Steve
> >

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web