Mengapa sudo -i saya tidak menetapkan XDG_RUNTIME_DIR untuk pengguna target?

XDG_RUNTIME_DIRdiperlukan untuk systemctl --userbekerja.

Saya telah menyiapkan server ubuntu 16.04 untuk menjalankan sesi pengguna systemd. Sekarang, ketika mencoba untuk mengelola mereka, saya menemukan bahwa ketika mengubah pengguna melalui sudo -u $user -iatau bahkan su - $user, lingkungan tidak XDG_RUNTIME_DIRdiatur, mencegah systemctl --userdari bekerja. Namun, ketika saya sshlangsung masuk ke pengguna itu, sudah diatur dengan benar.

Jika saya memahami dokumentasi dengan benar, ini harus ditetapkan libpam-systemdsaat membuat sesi pengguna. Iris pengguna dimulai dengan benar, karena direktori yang XDG_RUNTIME_DIRharus diarahkan ( /run/users/$uid) ada. Saya ragu-ragu untuk hanya memasukkannya ke dalam harddisk, katakanlah, .bash_profilekarena itu kelihatannya hacky (walaupun berfungsi), ketika pam harus mengurusnya.

Aku bisa, tentu saja, tambahkan XDG_RUNTIME_DIRke env_keepdalam sudoers, tapi itu hanya akan melestarikan lingkungan sudoing pengguna, yang tidak apa yang saya inginkan. Saya ingin lingkungan pengguna target .

Apa yang saya benar-benar bertanya-tanya adalah bagaimana sesi diatur dengan benar ssh, tetapi tidak dengan suatau sudo -i?

Saya telah mereplikasi masalah ini pada sistem Fedora 25 saya.

Saya menemukan kondisi yang sangat mencurigakan dalam kode sumber. https://github.com/systemd/systemd/blob/f97b34a/src/login/pam_systemd.c#L439 Tampaknya seolah-olah ditulis dengan normal sudotetapi tidak sudo -u non-root-user.

machinectl shell --uid=non-root-user bekerja seperti yang Anda minta.

systemd-run tampaknya tidak berfungsi seperti yang diinginkan, meskipun merujuk kepadanya dalam dokumentasi machinectl.

Beberapa perintah machinectl tidak berfungsi jika Anda telah mengaktifkan SELinux saat ini, dan perintah khusus ini tidak berfungsi untuk saya sampai saya melakukannya setenforce 0. Namun saya sedang mencoba mencari solusi agar mesin berfungsi seperti yang saya inginkan, SELinux, jadi mungkin saya mengutak-atik apa yang menyebabkan mis machinectl shell.

EDIT: Saya pikir kode ini diperkenalkan setelah diskusi ini . Dan ternyata su -/ sudo -ibisa dibuat untuk bekerja, tetapi belum ada yang menerapkannya (masih).

Apa yang saya benar-benar bertanya-tanya, bagaimana bisa sesi diatur dengan benar dengan ssh, tetapi tidak dengan su atau sudo -i?

https://github.com/systemd/systemd/issues/7451#issuecomment-346787237

Maaf, tetapi "su" adalah alat untuk mengubah identitas pengguna dan sangat sedikit kredensial proses lainnya untuk sementara. Ini bukan alat untuk membuka sesi login yang sama sekali baru. Sesi login baru memiliki pengaturan yang sangat jelas, murni, tidak mewarisi apa pun dari sesi lain, tapi ini benar-benar tidak terjadi untuk "perubahan": sebagian besar lingkungan eksekusi diwarisi, dalam banyak dan tidak jelas cara, misalnya konteks MAC, konteks audit, konteks cgroup, konteks namespace, penjadwalan, rincian waktu, ...

jika Anda ingin sesi baru yang lengkap, gunakan sesuatu seperti "login machinectl" atau "shell machinectl", yang sebenarnya akan membuat lingkungan Anda sepenuhnya bersih, independen, lepas, tanpa ada properti proses tersembunyi yang bocor dari tempat Anda menyebutnya.

sesi logind sebagian besar terikat pada konsep sesi audit, dan sesi audit tetap tidak terpengaruh oleh "su", pada kenyataannya mereka didefinisikan sebagai "ditutup", yaitu dengan cara bahwa jika suatu proses memasuki sesi sekali, ia akan selalu tetap dengan itu, dan begitu juga anak-anaknya, yaitu satu-satunya cara untuk mendapatkan sesi baru adalah dengan melepaskan sesuatu dari PID 1 (atau sesuatu yang serupa) yang tidak pernah menjadi bagian dari sesi.

Atau untuk mengatakan ini secara berbeda: hal-hal yang Anda panggil melalui "su" akan muncul dengan baik di "loginctl", namun, itu tetap menjadi bagian dari sesi asli Anda, Anda masuk log awalnya. Anda dapat memverifikasi itu dengan memanggil "status loginctl" pada ID sesi asli (yang dapat Anda lihat melalui echo $ XDG_SESSION_ID)