Início / unix / Perguntas / 491416
Accepted
炸鱼薯条德里克
Asked: 2018-12-29 21:51:03 +0800 CST

Como journald sabe o PID de um processo que produz dados de log?

  • 772

Quando olho para journalctl, ele me diz o PID e o nome do programa (ou nome do serviço?) de uma entrada de log.

Então eu me perguntei, os logs são criados por outros processos, como systemd-journaldsaber o PID desses processos quando os processos podem apenas gravar strings brutas no soquete do domínio unix que systemd-journaldestá ouvindo. Além disso, sytemd-journaldsempre use a mesma técnica para detectar o PID de um dado de log, mesmo quando os processos estiverem produzindo log usando funções como sd_journal_sendv()?

Existe alguma documentação que eu deveria ler sobre isso?

Eu li a resposta do JdeBP e sei systemd-journaldescutar em um Unix Domian Socket, mas mesmo sabendo o endereço do soquete do peer que envia a mensagem de log, como ele sabe o PID? E se esse soquete de envio for aberto por muitos processos não pai-filhos?

ipc systemd-journald

2 respostas

  1. Best Answer

    Ele recebe o pid através dos SCM_CREDENTIALSdados auxiliares no soquete unix com recvmsg(), veja unix(7). As credenciais não precisam ser enviadas explicitamente.

    Exemplo:

    $ cc -Wall scm_cred.c -o scm_cred
$ ./scm_cred
scm_cred: received from 10114: pid=10114 uid=2000 gid=2000

    Processos com CAP_SYS_ADMINdados podem enviar o pid que quiserem via SCM_CREDENTIALS; no caso de systemd-journald, isso significa que eles podem falsificar entradas como se fossem registradas por outro processo:

    # cc -Wall fake.c -o fake
# setcap CAP_SYS_ADMIN+ep fake

$ ./fake `pgrep -f /usr/sbin/sshd`

# journalctl --no-pager -n 1
...
Dec 29 11:04:57 debin sshd[419]: fake log message from 14202
# rm fake
# lsb_release -d
Description:    Debian GNU/Linux 9.6 (stretch)

    systemd-journaldmanipula datagramas e credenciais enviados por meio de dados auxiliares está na server_process_datagram()função de journald-server.c. Tanto a syslog(3)função padrão de libcquanto sd_journal_sendv()de libsystemdenviará seus dados por meio de um SOCK_DGRAMsoquete por padrão e getsockopt(SO_PEERCRED)não funciona em soquetes de datagrama (sem conexão). Nem systemd-journaldnem rsyslogdaceitar SOCK_STREAMconexões em /dev/log.

    scm_cred.c

    #define _GNU_SOURCE     1
#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>
#include <err.h>

int main(void){
        int fd[2]; pid_t pid;
        if(socketpair(AF_LOCAL, SOCK_DGRAM, 0, fd)) err(1, "socketpair");
        if((pid = fork()) == -1) err(1, "fork");
        if(pid){ /* parent */
                int on = 1;
                union {
                        struct cmsghdr h;
                        char data[CMSG_SPACE(sizeof(struct ucred))];
                } buf;
                struct msghdr m = {0};
                struct ucred *uc = (struct ucred*)CMSG_DATA(&buf.h);
                m.msg_control = &buf;
                m.msg_controllen = sizeof buf;
                if(setsockopt(fd[0], SOL_SOCKET, SO_PASSCRED, &on, sizeof on))
                        err(1, "setsockopt");
                if(recvmsg(fd[0], &m, 0) == -1) err(1, "recvmsg");
                warnx("received from %d: pid=%d uid=%d gid=%d", pid,
                        uc->pid, uc->uid, uc->gid);
        }else   /* child */
                write(fd[1], 0, 0);
        return 0;
}

    fake.c

    #define _GNU_SOURCE     1
#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <err.h>

int main(int ac, char **av){
        union {
                struct cmsghdr h;
                char data[CMSG_SPACE(sizeof(struct ucred))];
        } cm;
        int fd; char buf[256];
        struct ucred *uc = (struct ucred*)CMSG_DATA(&cm.h);
        struct msghdr m = {0};
        struct sockaddr_un ua = {AF_UNIX, "/dev/log"};
        struct iovec iov = {buf};
        if((fd = socket(AF_LOCAL, SOCK_DGRAM, 0)) == -1) err(1, "socket");
        if(connect(fd, (struct sockaddr*)&ua, SUN_LEN(&ua))) err(1, "connect");
        m.msg_control = &cm;
        m.msg_controllen = cm.h.cmsg_len = CMSG_LEN(sizeof(struct ucred));
        cm.h.cmsg_level = SOL_SOCKET;
        cm.h.cmsg_type = SCM_CREDENTIALS;
        uc->pid = ac > 1 ? atoi(av[1]) : getpid();
        uc->uid = ac > 2 ? atoi(av[2]) : geteuid();
        uc->gid = ac > 3 ? atoi(av[3]) : getegid();
        iov.iov_len = snprintf(buf, sizeof buf, "<13>%s from %d",
                ac > 4 ? av[4] : "fake log message", getpid());
        if(iov.iov_len >= sizeof buf) errx(1, "message too long");
        m.msg_iov = &iov;
        m.msg_iovlen = 1;
        if(sendmsg(fd, &m, 0) == -1) err(1, "sendmsg");
        return 0;
}
    • 5

  2. O kernel diz isso.

    O EUID, EGID e PID do processo cliente original que conectou o AF_LOCALsoquete de fluxo em /run/systemd/journal/stdoutestá disponível no kernel por meio da SO_PEERCREDopção de soquete, que ele usa . As ferramentas UCSPI-UNIX obtêm esta mesma informação através da mesma chamada de sistema.

    É claro que os processos de serviço filho herdam seus descritores de arquivo de E/S padrão já abertos (a menos que o processo de serviço pai altere isso, é claro) e, portanto, systemd-journaldtodas as saídas de log têm as credenciais do processo pai original.

    A saída de log gerada através do AF_LOCALsoquete em /run/systemd/journal/socketque fala que o systemd-journaldprotocolo idiossincrático está vindo de um soquete de datagrama, em vez de um fluxo. Este socket é sinalizado usando a SO_PASSCREDopção socket para que o kernel registre a mesma informação em cada datagrama enviado, que é retirado de cada datagrama por systemd-journald.

    Leitura adicional

    • 1

relate perguntas