systemd-journald
기본 구성에서는 SplitMode=uid
각 사용자에 대해 별도의 로그(log) 파일이 생성되고 사용자가 읽을 수 있도록 허용됩니다.
실행 중인 서비스를 사용할 때 DynamicUser=
이는 서비스가 DynamicUser=
임의의 오래된 서비스 로그를 읽을 수 있다는 의미입니까?
그렇다면 완전히 자신의 로그 파일이 아닌 로그 파일을 읽을 수 있는 데 잠재적인 문제(보안?)가 있습니까?
편집: 시스템에 코어 덤프를 별도의 파일이나 로그로 저장하는 것에 대해 우려하는 사람이 있습니까? (시스템 코어 덤프)
DynamicUser=의 블로그 게시물에서는 UID 재사용의 영향을 논의할 때 저널을 언급하지 않습니다.
http://0pointer.net/blog/dynamic-users-with-systemd.html
시스템 사용자를 등록한 패키지가 시스템(적어도 대부분의 배포판에서는)에서 제거될 때 시스템 사용자가 일반적으로 해제되지 않는 이유가 궁금할 수 있습니다. 그 이유는 사용자 개념의 관련 속성 때문입니다(설계 결함이라고 부르고 싶을 수도 있음). 사용자 ID는 파일(및 IPC 개체와 같은 다른 개체)에 붙어 있습니다. 특정 시스템 사용자로 실행되는 서비스가 특정 위치에 파일을 생성한 후 해당 패키지와 사용자를 종료하고 삭제하는 경우 생성된 파일은 원래 시스템 사용자가 할당한 숫자 ID("UID")에 계속 속하게 됩니다. 다음 시스템 사용자가 할당되고 ID 재활용으로 인해 동일한 숫자 ID가 할당되면 해당 파일에도 액세스하게 되는데, 이는 파일이 매우 다른 서비스에 속할 수 있으므로 일반적으로 문제로 간주됩니다. , 그 이후에는 읽거나 변경해서는 안 됩니다. 따라서 할당은 UID 재활용을 피하는 경향이 있습니다. 즉, 시스템 사용자는 한 번 할당된 후 시스템에 영원히 등록됩니다.
...
이 문제를 해결하기 위해 다음 두 가지 전략을 쉽게 생각할 수 있습니다.
서비스가 파일/디렉터리 또는 IPC 객체를 생성하는 것을 허용하지 않습니다.
서비스 종료 시 생성된 파일/디렉터리 또는 IPC 개체를 자동으로 삭제합니다.
systemd에서는 두 가지 전략을 모두 구현하지만 실행 환경의 다른 부분에 대해 ...
답변1
보안 문제는 없습니다. (systemd v239를 확인했습니다).
DynamicUser=에서 사용하는 UID 범위의 사용자는 자신의 시스템 로그 또는 시스템 코어 덤프를 읽을 수 없습니다. "시스템" 사용자(일반적으로 UID < 1000) 및 nobody
.
https://github.com/systemd/systemd/blob/v239/src/coredump/coredump.c#L157
if (uid_is_system(uid) || uid_is_dynamic(uid) || uid == UID_NOBODY)
return 0;
/* Make sure normal users can read (but not write or delete)
* their own coredumps */
https://github.com/systemd/systemd/blob/v239/src/journal/journald-server.c#L225
static bool uid_for_system_journal(uid_t uid) {
/* Returns true if the specified UID shall get its data stored in the system journal*/
return uid_is_system(uid) || uid_is_dynamic(uid) || uid == UID_NOBODY;
}
답변2
SplitMode=uid는 로그가 각 사용자의 서로 다른 systemd 인스턴스에 대한 여러 파일로 분할되고, uid가 1000인 systemd의 pid1(시스템 로그)에 대한 파일로 분할되며 이에 따라 로그 데몬에 의해 액세스 모드가 설정됨을 의미합니다. 현재로서는 다른 방법으로 분할할 수 없습니다. 이는 안타까운 일이라고 생각합니다.