dh, the daemon helper - Unix

This is a discussion on dh, the daemon helper - Unix ; Rainer Weikusat writes: > Nate Eldredge writes: >> Rainer Weikusat writes: >>> Strictly speaking, keeping sensitive data on a system accessible by >>> untrusted parties is such a mistake, too, because it is (at least >>> theoretically) possible that these ...

+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4
Results 61 to 70 of 70

Thread: dh, the daemon helper

  1. Re: dh, the daemon helper

    Rainer Weikusat writes:

    > Nate Eldredge writes:
    >> Rainer Weikusat writes:
    >>> Strictly speaking, keeping sensitive data on a system accessible by
    >>> untrusted parties is such a mistake, too, because it is (at least
    >>> theoretically) possible that these 'untrusted parties' could manage to
    >>> elevate their own privileges by exploiting errors in software they
    >>> have been granted access to.

    >>
    >> Right, so that leaves us with computers that are not on networks, locked
    >> up in guarded rooms, and encased in concrete.

    >
    > Better fill the case with concrete instead. The only way something can
    > be made 'secure against abuse' is by eliminating 'use'. But you are
    > much more secure if you fill the computer case with concrete than if
    > you just randomly disable useful functionality.


    Good point. Let's blow up the computer, incinerate the fragments, and
    shoot the ashes into the sun. Then it will be safe to enable core
    dumps.

    ;-)

    Seriously, I don't think we're going to agree on this issue. But you
    did raise a number of important points and helped me think about it more
    clearly.

  2. Re: dh, the daemon helper

    In article <8663n7w9wa.fsf@vulcan.lan>, Nate Eldredge wrote:

    > vippstar@gmail.com writes:
    >
    > > On Nov 1, 7:11 pm, Rainer Weikusat wrote:
    > >> Since programming initially running as this process is supposed to go
    > >> away 'soon' (it's only purpose is to start another program), there is
    > >> no point in returning memory to the malloc heap.

    > >
    > > You're wrong. IEEE 1003.1, 2004 doesn't guarantee that upon exit of
    > > the program the memory will be freed.

    >
    > That is true, but I'd be inclined to regard that as a defect in the
    > standard. The description of _exit() is so explicit about the many
    > things it frees and destroys that it is hard to imagine the authors
    > intended to require it to do all that, but not do something as basic as
    > free the process's memory.


    C is not restricted to Unix.

    > Nevertheless, every IEEE-1003.1-compliant, or otherwise Unix-like,


    Do any still honor mode 01555?

    --
    I'm not even supposed to be here today.

    I ASSURE YOU WE'RE OPEN!

  3. Re: dh, the daemon helper

    vippstar@gmail.com wrote:

    > On Nov 3, 8:28 pm, John Kelly wrote:
    >> On Nov 3, 12:46 pm, Eric Sosman wrote:
    >>
    >> > You can get garbage with a possible alert or garbage with silence,
    >> > but either way it's garbage.

    >>
    >> Including null terminated strings in a language design was one of the
    >> worst programming ideas, ever. When program correctness depends on the
    >> value of some data, you're in big trouble to start with. Let's face
    >> it, C is garbage. Getting a C program to do anything useful is a
    >> reason to be happy.

    >
    > C serves its purpose well, it's not garbage. You haven't explained why
    > having such strings was one of the worst programming ideas ever, plus,
    > what alternatives do you have in mind?


    A problem with NUL-terminated (an ASCII NUL - not to be confused with NULL)
    strings, is that they are inefficient with some forms of data processing.

    If you use strlen() with strings that are megabytes long, it will be too
    slow for most uses. That char at a time iteration can be costly, though
    some implementations require padding bytes to work with larger types than a
    char, and thus reduce the cost somewhat.

    strcpy isn't as efficient as memcpy is general, because strcpy has to
    consider the NUL, and test every char, while memcpy can copy using
    instructions that operate on elements larger than a char. Some
    implementations of memcpy may copy (once aligned to a proper address) 16
    bytes or more at once using substantially fewer instructions.

    There are plenty of string libraries for C, but when the syscalls and C
    libraries don't use those, it makes it more difficult to adopt a better
    standard string. The security problems associated with C strings are
    another issue, though I consider that more of an interface design issue.
    gets() was used originally, but I don't think you'll find many people using
    it in apps these days.

    The data sets that people use now aren't like what the unix designers used
    originally. Try future proofing everything, and the future will pass you
    by.

    Garbage is subjective, so one can debate the point of C being garbage using
    a lot of emotional reasoning. If it works, use it. One man's trash is
    another man's treasure.

    --George

  4. Re: dh, the daemon helper

    S M Ryan writes:

    > In article <8663n7w9wa.fsf@vulcan.lan>, Nate Eldredge wrote:
    >
    >> vippstar@gmail.com writes:
    >>
    >> > On Nov 1, 7:11 pm, Rainer Weikusat wrote:
    >> >> Since programming initially running as this process is supposed to go
    >> >> away 'soon' (it's only purpose is to start another program), there is
    >> >> no point in returning memory to the malloc heap.
    >> >
    >> > You're wrong. IEEE 1003.1, 2004 doesn't guarantee that upon exit of
    >> > the program the memory will be freed.

    >>
    >> That is true, but I'd be inclined to regard that as a defect in the
    >> standard. The description of _exit() is so explicit about the many
    >> things it frees and destroys that it is hard to imagine the authors
    >> intended to require it to do all that, but not do something as basic as
    >> free the process's memory.

    >
    > C is not restricted to Unix.


    But this newsgroup is. So I only intended my remarks to apply in that
    context.

    [off-topic]

    The corresponding question with regard to ISO C is somewhat
    controversial. See http://c-faq.com/malloc/freeb4exit.html . I myself
    have not formed an opinion.

    >> Nevertheless, every IEEE-1003.1-compliant, or otherwise Unix-like,

    >
    > Do any still honor mode 01555?


    Sorry, you've lost me.


  5. Re: dh, the daemon helper

    On Nov 5, 7:19 am, GPS wrote:
    > vipps...@gmail.com wrote:
    > > On Nov 3, 8:28 pm, John Kelly wrote:
    > >> Including null terminated strings in a language design was one of the
    > >> worst programming ideas, ever. When program correctness depends on the
    > >> value of some data, you're in big trouble to start with. Let's face
    > >> it, C is garbage. Getting a C program to do anything useful is a
    > >> reason to be happy.

    >
    > > C serves its purpose well, it's not garbage. You haven't explained why
    > > having such strings was one of the worst programming ideas ever, plus,
    > > what alternatives do you have in mind?

    >
    > A problem with NUL-terminated (an ASCII NUL - not to be confused with NULL)
    > strings, is that they are inefficient with some forms of data processing.


    C doesn't require the implementation to use ASCII. Does that mean
    EBCDIC NUL-terminated strings don't suffer from such inefficiency?

    > If you use strlen() with strings that are megabytes long, it will be too
    > slow for most uses. That char at a time iteration can be costly, though
    > some implementations require padding bytes to work with larger types than a
    > char, and thus reduce the cost somewhat.


    If you use strlen on such strings, you're probably a silly programmer.
    That's like blaming lisp because you iterated a huge list.

    > strcpy isn't as efficient as memcpy is general, because strcpy has to
    > consider the NUL, and test every char, while memcpy can copy using
    > instructions that operate on elements larger than a char. Some
    > implementations of memcpy may copy (once aligned to a proper address) 16
    > bytes or more at once using substantially fewer instructions.


    The efficiency of both functions is a QoI but i don't see how any
    implementation will do better than O(n).

    > There are plenty of string libraries for C, but when the syscalls and C
    > libraries don't use those, it makes it more difficult to adopt a better
    > standard string. The security problems associated with C strings are
    > another issue, though I consider that more of an interface design issue.
    > gets() was used originally, but I don't think you'll find many people using
    > it in apps these days.


    You can use your string library completely, and ditch all the C
    standard functions.

    > The data sets that people use now aren't like what the unix designers used
    > originally. Try future proofing everything, and the future will pass you
    > by.


    That's all fine - you still haven't mentioned an alternative to those
    "horrible" strings.


  6. Re: dh, the daemon helper

    S M Ryan writes:
    > In article <8663n7w9wa.fsf@vulcan.lan>, Nate Eldredge wrote:
    >> vippstar@gmail.com writes:
    >>
    >> > On Nov 1, 7:11 pm, Rainer Weikusat wrote:
    >> >> Since programming initially running as this process is supposed to go
    >> >> away 'soon' (it's only purpose is to start another program), there is
    >> >> no point in returning memory to the malloc heap.
    >> >
    >> > You're wrong. IEEE 1003.1, 2004 doesn't guarantee that upon exit of
    >> > the program the memory will be freed.

    >>
    >> That is true, but I'd be inclined to regard that as a defect in the
    >> standard. The description of _exit() is so explicit about the many
    >> things it frees and destroys that it is hard to imagine the authors
    >> intended to require it to do all that, but not do something as basic as
    >> free the process's memory.


    [...]

    >> Nevertheless, every IEEE-1003.1-compliant, or otherwise Unix-like,

    >
    > Do any still honor mode 01555?


    There is no C-level library call which could be used to free 'the text
    segment of the process'.

  7. Re: dh, the daemon helper

    GPS writes:
    > vippstar@gmail.com wrote:


    [...]

    > There are plenty of string libraries for C, but when the syscalls and C
    > libraries don't use those, it makes it more difficult to adopt a better
    > standard string.


    There is no such thing as 'a better standard string'. Depending on the
    requirements of a particular situation, either using a marker
    element at the end (which is similar to the way the end of a linked
    list is dealt with) or using explicit lengths is the more sensible
    choice. The C-library contains a set of (mostly trivial) routines
    which operate on end-marker strings. These are occasionally useful.
    System calls expect them, too, because otherwise, each 'string'
    argument would need to be 'two arguments', while the system call will
    usually have to process all of the string, anyway (an example would be
    pathname lookup).

    > The security problems associated with C strings are
    > another issue,


    There are no 'security problems associated with C strings'. People can
    (and do) misuse end-marker strings, just as they can (and do) misuse
    anything else available to them. Some programming errors have a
    so-called 'security impact', because they enable people to get access
    to a privilege level higher than the one they would ordinarily have
    access to by 'tricking' a program running on their behalf with
    elevated privileges into letting them perform operations at this
    privilege level the program was not supposed to make available to
    them.

    Indepently of this, the main infection route of the Morris Worm
    (and that's really OLD by now) was not sendmail, as the convenient rumour
    goes, but the BSD fingerd, which read 'a line of input' from the
    network into a finite-sized buffer using gets.

    > though I consider that more of an interface design issue.
    > gets() was used originally, but I don't think you'll find many
    > people using it in apps these days.


    Oh, I use it. It is convenient for programs where the input is known
    to come from a trusted source, eg only intended to be used for a short
    time by the person who wrote the code. Even when being used in more
    general applications, it's just a bad practice and not necessarily
    dangerous (who cares if some user manages to crash a process he
    started?). But - of course - it must not be used when the input source
    is known to be not trustworthy, eg for anything which runs (as
    mentioned above) at a privilege level not ordinarily accessible to the
    people providing the input, part of whose functionality is to confine
    these people to a particular set of well-defined operations.

    But this would mean the person responsible for the Morris Worm would
    either have been the person who wrote the braindead code or the
    'supervising person' (insofar one existed) who did not prevent its
    inclusion (and default activation) in the corresponding BSD-release.
    And one of the nice properties of dramatic software errors is that,
    insofer the blame cannot be put onto an unknown student whose traces
    are lost who happened to work for the company twenty years ago, noone
    is responsible, because all were just victims of the unfavourable
    circumstances.

    [...]

    > Garbage is subjective, so one can debate the point of C being garbage using
    > a lot of emotional reasoning.


    C hasn't been designed to be well-formed according to a certain theory
    which claims to be a theory of programming languages (insofar I know
    this). Yet it exists, works and has been wildly successful. No wonder
    that opponents tend to get 'emotional' in face of that.

  8. Re: dh, the daemon helper

    vippstar@gmail.com wrote:

    > On Nov 5, 7:19 am, GPS wrote:
    >> vipps...@gmail.com wrote:
    >> > On Nov 3, 8:28 pm, John Kelly wrote:
    >> >> Including null terminated strings in a language design was one of the
    >> >> worst programming ideas, ever. When program correctness depends on the
    >> >> value of some data, you're in big trouble to start with. Let's face
    >> >> it, C is garbage. Getting a C program to do anything useful is a
    >> >> reason to be happy.

    >>
    >> > C serves its purpose well, it's not garbage. You haven't explained why
    >> > having such strings was one of the worst programming ideas ever, plus,
    >> > what alternatives do you have in mind?

    >>
    >> A problem with NUL-terminated (an ASCII NUL - not to be confused with
    >> NULL) strings, is that they are inefficient with some forms of data
    >> processing.

    >
    > C doesn't require the implementation to use ASCII. Does that mean
    > EBCDIC NUL-terminated strings don't suffer from such inefficiency?


    EBCDIC has a NUL character. It's also similar to ASCII in some other ways
    as well. You can find a comparison table online.

    >
    >> If you use strlen() with strings that are megabytes long, it will be too
    >> slow for most uses. That char at a time iteration can be costly, though
    >> some implementations require padding bytes to work with larger types than
    >> a char, and thus reduce the cost somewhat.

    >
    > If you use strlen on such strings, you're probably a silly programmer.
    > That's like blaming lisp because you iterated a huge list.


    I disagree here. The primitive strings in some other languages are always
    counted strings, with an associated length. Suppose for example that you
    write a text processing tool using strlen. It works fine the first round,
    but let's say you later process gigabytes of data. Now you have to go and
    redesign the solution, because of strlen. _The Practice of Programming_
    (by Kernighan and Pike) has an example of such a problem I believe as well.
    Thus, scalability can be a problem with strlen-based solutions.

    >> strcpy isn't as efficient as memcpy is general, because strcpy has to
    >> consider the NUL, and test every char, while memcpy can copy using
    >> instructions that operate on elements larger than a char. Some
    >> implementations of memcpy may copy (once aligned to a proper address) 16
    >> bytes or more at once using substantially fewer instructions.

    >
    > The efficiency of both functions is a QoI but i don't see how any
    > implementation will do better than O(n).


    It probably won't, but big O notation is just a rough estimate.

    It's really like comparing: strcpy: O(n) to memcpy: O(n / 16) in terms of
    machine instructions and bus traffic, depending on the implementation.

    >> The data sets that people use now aren't like what the unix designers
    >> used
    >> originally. Try future proofing everything, and the future will pass you
    >> by.

    >
    > That's all fine - you still haven't mentioned an alternative to those
    > "horrible" strings.


    I don't think they are horrible. I just think they aren't always ideal.
    Some languages store the length of a string at the very start of the
    string's memory. So the actual string characters might start at offset str
    + 4 or str + 8, depending on the size of the length for the string.

    George

  9. Re: dh, the daemon helper

    On Wed, 05 Nov 2008 12:04:23 +0100, Rainer Weikusat
    wrote:

    >C hasn't been designed to be well-formed according to a certain theory
    >which claims to be a theory of programming languages (insofar I know
    >this). Yet it exists, works ...


    .... like a venus flytrap.


    >and has been wildly successful ...


    .... at wasting the time and resources of an entire generation of
    unsuspecting programmers and end users who imagine blue screens and
    other failures to be a natural consequence of technology.

    The colossal technologic infrastructure, from Sun to Microsoft, built
    on C, is a house of cards, destined for ultimate collapse.


    --
    Webmail for Dialup Users
    http://www.isp2dial.com/freeaccounts.html


  10. Re: dh, the daemon helper

    On Nov 5, 4:34 pm, GPS wrote:
    > vipps...@gmail.com wrote:
    > > On Nov 5, 7:19 am, GPS wrote:
    > >> A problem with NUL-terminated (an ASCII NUL - not to be confused with
    > >> NULL) strings, is that they are inefficient with some forms of data
    > >> processing.

    >
    > > C doesn't require the implementation to use ASCII. Does that mean
    > > EBCDIC NUL-terminated strings don't suffer from such inefficiency?

    >
    > EBCDIC has a NUL character. It's also similar to ASCII in some other ways
    > as well. You can find a comparison table online.


    Yes it does. My point is that you seemed to be blaming the charset
    instead of the current definition of a string.

    > >> If you use strlen() with strings that are megabytes long, it will be too
    > >> slow for most uses. That char at a time iteration can be costly, though
    > >> some implementations require padding bytes to work with larger types than
    > >> a char, and thus reduce the cost somewhat.

    >
    > > If you use strlen on such strings, you're probably a silly programmer.
    > > That's like blaming lisp because you iterated a huge list.

    >
    > I disagree here. The primitive strings in some other languages are always
    > counted strings, with an associated length. Suppose for example that you
    > write a text processing tool using strlen. It works fine the first round,
    > but let's say you later process gigabytes of data. Now you have to go and
    > redesign the solution, because of strlen. _The Practice of Programming_
    > (by Kernighan and Pike) has an example of such a problem I believe as well.
    > Thus, scalability can be a problem with strlen-based solutions.


    But whose fault is that? Isn't it the programmers fault for having a
    problematic design?

    > >> strcpy isn't as efficient as memcpy is general, because strcpy has to
    > >> consider the NUL, and test every char, while memcpy can copy using
    > >> instructions that operate on elements larger than a char. Some
    > >> implementations of memcpy may copy (once aligned to a proper address) 16
    > >> bytes or more at once using substantially fewer instructions.

    >
    > > The efficiency of both functions is a QoI but i don't see how any
    > > implementation will do better than O(n).

    >
    > It probably won't, but big O notation is just a rough estimate.
    >
    > It's really like comparing: strcpy: O(n) to memcpy: O(n / 16) in terms of
    > machine instructions and bus traffic, depending on the implementation.


    Well, there isn't such thing as 'O(n/16)'. O(n/16) is O(n).

    > >> The data sets that people use now aren't like what the unix designers
    > >> used
    > >> originally. Try future proofing everything, and the future will pass you
    > >> by.

    >
    > > That's all fine - you still haven't mentioned an alternative to those
    > > "horrible" strings.

    >
    > I don't think they are horrible. I just think they aren't always ideal.


    That's true, and it's a good thing C doesn't enforce them. I think
    they're minimalistic, which is a good thing, considering C's goal.


+ Reply to Thread
Page 4 of 4 FirstFirst ... 2 3 4