Doug / smarc-fsl-linux-kernel

26 Apr, 2007

1 commit

  • 92f37fd2e   [NET]: Adding SO_TIMESTAMPNS / SCM_TIMESTAMPNS support ... Browse Code »

    Now that network timestamps use ktime_t infrastructure, we can add a new
    SOL_SOCKET sockopt SO_TIMESTAMPNS.

    This command is similar to SO_TIMESTAMP, but permits transmission of
    a 'timespec struct' instead of a 'timeval struct' control message.
    (nanosecond resolution instead of microsecond)

    Control message is labelled SCM_TIMESTAMPNS instead of SCM_TIMESTAMP

    A socket cannot mix SO_TIMESTAMP and SO_TIMESTAMPNS : the two modes are
    mutually exclusive.

    sock_recv_timestamp() became too big to be fully inlined so I added a
    __sock_recv_timestamp() helper function.

    Signed-off-by: Eric Dumazet
    CC: linux-arch@vger.kernel.org
    Signed-off-by: David S. Miller

    Eric Dumazet
     

30 Jun, 2006

1 commit

  • 877ce7c1b   [AF_UNIX]: Datagram getpeersec ... Browse Code »

    This patch implements an API whereby an application can determine the
    label of its peer's Unix datagram sockets via the auxiliary data mechanism of
    recvmsg.

    Patch purpose:

    This patch enables a security-aware application to retrieve the
    security context of the peer of a Unix datagram socket. The application
    can then use this security context to determine the security context for
    processing on behalf of the peer who sent the packet.

    Patch design and implementation:

    The design and implementation is very similar to the UDP case for INET
    sockets. Basically we build upon the existing Unix domain socket API for
    retrieving user credentials. Linux offers the API for obtaining user
    credentials via ancillary messages (i.e., out of band/control messages
    that are bundled together with a normal message). To retrieve the security
    context, the application first indicates to the kernel such desire by
    setting the SO_PASSSEC option via getsockopt. Then the application
    retrieves the security context using the auxiliary data mechanism.

    An example server application for Unix datagram socket should look like this:

    toggle = 1;
    toggle_len = sizeof(toggle);

    setsockopt(sockfd, SOL_SOCKET, SO_PASSSEC, &toggle, &toggle_len);
    recvmsg(sockfd, &msg_hdr, 0);
    if (msg_hdr.msg_controllen > sizeof(struct cmsghdr)) {
    cmsg_hdr = CMSG_FIRSTHDR(&msg_hdr);
    if (cmsg_hdr->cmsg_len cmsg_level == SOL_SOCKET &&
    cmsg_hdr->cmsg_type == SCM_SECURITY) {
    memcpy(&scontext, CMSG_DATA(cmsg_hdr), sizeof(scontext));
    }
    }

    sock_setsockopt is enhanced with a new socket option SOCK_PASSSEC to allow
    a server socket to receive security context of the peer.

    Testing:

    We have tested the patch by setting up Unix datagram client and server
    applications. We verified that the server can retrieve the security context
    using the auxiliary data mechanism of recvmsg.

    Signed-off-by: Catherine Zhang
    Acked-by: Acked-by: James Morris
    Signed-off-by: David S. Miller

    Catherine Zhang
     

30 Aug, 2005

1 commit

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds