[lkml]   [2009]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Security: Implement and document RLIMIT_NETWORK.
    On Wed, Jan 07, 2009 at 04:07:58PM -0500, Michael Stone ( wrote:
    > First, thanks very much for all your comments and questions.

    you are welcome :)

    > >It isn't, since it can not set rlimit, and if it can, it still can drop
    > >it.
    > Some sample code will probably clarify the use of my patch:
    > This C code describes a 'disable_network' exec-chain script which, when run
    > as
    > any user, irrevocably disables network access as described in my previous
    > emails.
    > As you can see, processes start with full access to the 'network' resource
    > and
    > may, at any time, irrevocably (modulo CAP_SYS_RESOURCE) limit their and
    > their
    > future children's access to this resource by lowering both their soft and
    > hard
    > limits to 0.

    Argh, I see. That clarifies most questions indeed.

    > >Your code does not cover sendpage() interface (aka splice() and
    > >sendfile())
    > Nor should it. Applications should continue to be able to send data on any
    > sockets where were already connected and should be able to accept new
    > connections on sockets which were already bound.
    > I have done some primitive testing to ensure that the patch implements this
    > functionality by means of the test utilities provided here:
    > Can you confirm my results?

    Your patch adds a rlimit check into __sock_sendmsg() call, which is
    invoked via usual send() path, but sendfile() and splice() are still
    exectuted without this check and thus will be able to send data after
    rlimit applied.

    > >and with your approach application will suddenly stops sending data even
    > >into
    > >old sockets, but will be able to receive it from anywhere. Is it
    > >intentional?
    > Why do you think this would happen?
    > (My test results, e.g. via
    > show otherwise.)

    I meant that connected or accepted socket will not be able to send data
    via send() call, but will be able to receive data using recv().

    Evgeniy Polyakov

     \ /
      Last update: 2009-01-07 23:03    [W:0.023 / U:18.864 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site