coredump созданный под пользователем не читаем для пользователя. $ coredumpctl gdb PID: 1699072 (neomutt) UID: 500 (vt) Signal: 11 (SEGV) Timestamp: Mon 2025-04-21 01:41:00 MSK (15min ago) Command Line: neomutt Executable: /usr/bin/neomutt Control Group: /user.slice/user-500.slice/session-2005.scope Unit: session-2005.scope Slice: user-500.slice Session: 2005 Owner UID: 500 (vt) Boot ID: 03abba8b7e084e27816f51dca72fc4a1 Machine ID: d22b3ff7d165468497a3bcd66058be11 Storage: /var/lib/systemd/coredump/core.neomutt.500.03abba8b7e084e27816f51dca72fc4a1.1699072.1745188860000000.zst (inaccessible) Message: Process 1699072 (neomutt) of user 500 dumped core. Stack trace of thread 1699072: #0 0x00005611612c73ed imap_sync_mailbox (/usr/bin/neomutt + 0x1193ed) #1 0x00005611611fc9a6 mx_mbox_close (/usr/bin/neomutt + 0x4e9a6) #2 0x0000561161214ca8 op_quit (/usr/bin/neomutt + 0x66ca8) #3 0x00005611612183ab index_function_dispatcher (/usr/bin/neomutt + 0x6a3ab) #4 0x000056116120cd0d dlg_index (/usr/bin/neomutt + 0x5ed0d) #5 0x00005611611dd8a7 main (/usr/bin/neomutt + 0x2f8a7) #6 0x00007f255d339d6a __libc_start_call_main (libc.so.6 + 0x29d6a) #7 0x00007f255d339e25 __libc_start_main_impl (libc.so.6 + 0x29e25) #8 0x00005611611ddfc1 _start (/usr/bin/neomutt + 0x2ffc1) ELF object binary architecture: AMD x86-64 Failed to open /var/lib/systemd/coredump/core.neomutt.500.03abba8b7e084e27816f51dca72fc4a1.1699072.1745188860000000.zst: Permission denied $ ls -l /var/lib/systemd/coredump/core.neomutt.500.03abba8b7e084e27816f51dca72fc4a1.1699072.1745188860000000.zst -rw-r----- 1 root root 49659086 Apr 21 01:41 /var/lib/systemd/coredump/core.neomutt.500.03abba8b7e084e27816f51dca72fc4a1.1699072.1745188860000000.zst Это немного снижает пользу от coredumpctl.
Присутствует ли на сжатой корке ACL? Если нет, то, может, на /var/lib сломаны ACL, и дело в этом? Написал ли coredumpd об этом в логи?
На core.neomutt.*.zst нет acl (при этом на ней есть user.coredump xattr). systemd-coredump в журнале про это ничего (и никаких других ошибок) не писал. Apr 21 01:41:00 й systemd-coredump[1700328]: Process 1699072 (neomutt) of user 500 terminated abnormally with signal 11/SEGV, processing... Apr 21 01:41:01 й systemd-coredump[1700329]: Process 1699072 (neomutt) of user 500 dumped core.
(In reply to Vitaly Chikunov from comment #2) > На core.neomutt.*.zst нет acl (при этом на ней есть user.coredump xattr). https://github.com/systemd/systemd/blob/34c10968cbe3b5591b3c0ce225b8694edd9709d0/src/journal/coredump.c#L164 160 static int fix_xattr(int fd, char *argv[]) { 161 int r = 0; 162 163 /* Attach some metadate to coredumps via extended 164 * attributes. Just because we can. */
(In reply to Vitaly Chikunov from comment #2) > На core.neomutt.*.zst нет acl. > systemd-coredump в журнале про это ничего (и никаких других ошибок) не писал. https://github.com/systemd/systemd/blob/v257.5/src/coredump/coredump.c#L249 Появилось, кажется, тут: https://github.com/systemd/systemd/blob/34c10968cbe3b5591b3c0ce225b8694edd9709d0/src/journal/coredump.c#L118 как и установка xattr.
Установка xattr мне не нужна и не интересна, я лишь сказал, что она есть на случай если это чем-то поможет. Если это не помогает, то считайте, пожалуйста, что я про это не говорил.
(In reply to Vitaly Chikunov from comment #5) > Установка xattr мне не нужна и не интересна, я лишь сказал, что она есть на > случай если это чем-то поможет. Если это не помогает, то считайте, > пожалуйста, что я про это не говорил. Да это понятно; меня процитированный в comment 3 фрагмент исходника про xattr позабавил. К делу это отношения не имеет. Вот как сохранённая корка у меня на одной из машин выглядит: % getfacl /var/lib/systemd/coredump/core.zig2.1000.fcb63df0c80f45988701bd0b23367111.654.1744471718000000.zst getfacl: Removing leading '/' from absolute path names # file: var/lib/systemd/coredump/core.zig2.1000.fcb63df0c80f45988701bd0b23367111.654.1744471718000000.zst # owner: root # group: root user::rw- user:ar:r-- group::r-- mask::r-- other::--- Предлагаю попробовать в /var/lib от root создать файл с dac-правами 0400, с ACL-записью о том, что, мол, усеру vt разрешить `r--`. Может, от руки тоже не получится это сделать?
Вручную установить u:vt:r получается, так что дело не в fs.
See also: https://github.com/systemd/systemd/commit/3e4d0f6cf99f8677edd6a237382a65bfe758de03
neomutt не suid. -rwxr-xr-x 1 root root 1985056 Apr 10 17:56 /usr/bin/neomutt
Понятно. system-uid-max=999. fix_acl:: if (uid_is_system(uid) || uid_is_dynamic(uid) || uid == UID_NOBODY) return 0; Решение, видимо, только помнеть UID пользователю.
Наверное, более умная и обратно совместимая проверка могла бы быть другой. Например, если пользователь имеет shell, то можно предоставлять ему доступ. Или если uid_is_system, но пользователь в группе wheel, то наверное он сисадмин и можно дать ему доступ.
(In reply to Vitaly Chikunov from comment #11) > Наверное, более умная и обратно совместимая проверка могла бы быть другой. > Например, если пользователь имеет shell, то можно предоставлять ему доступ. Свести к этому вопросу uid_is_system() — это умная идея (причём не только для coredumpd, а вообще). Но, чтобы это узнать, на сегодняшний день нужно сходить к nss. Дешёвое системное решение — ввести отдельный файл с системными уидами, который синхронизировать с базовой локальной password database, и во всём софте предикат uid_is_system сводить к этому файлу. У такого решения как минимум те же недостатки, что и у обычного /etc/passwd (ключевые слова chroot(2), PR_SET_NO_NEW_PRIVS) Другое системное решение — сервер усеров, такой accountsservice здорового человека. Это решает тонну похожих задач одним махом, сильно упрощает жизнь в доменных организациях. systemd-userdbd, говорят, стремится стать такой службой, но я на сегодняшний день в нём разбираюсь плохо.
