Sudo -i neden hedef kullanıcı için XDG_RUNTIME_DIR ayarlamıyor?

XDG_RUNTIME_DIRsystemctl --userçalışmak için gereklidir .

Systemd kullanıcı oturumlarını çalıştırmak için ubuntu sunucusu 16.04 ayarladım. Şimdi, onları yönetmeye çalışırken, bir kullanıcıyı sudo -u $user -iveya hatta değiştirirken su - $user, ortamın XDG_RUNTIME_DIRayarlanmadığını systemctl --userve çalışmasını önlediğini görüyorum . Ancak, sshdoğrudan bu kullanıcıya girdiğimde doğru ayarlanmış.

Belgeleri doğru libpam-systemdanlarsam, kullanıcı oturumu oluşturulurken bu ayarın yapılması gerekir . Kullanıcı dilimi, XDG_RUNTIME_DIR( /run/users/$uid) noktasının bulunması gereken dizin olarak doğru şekilde başlatılır . Sadece sabit kodlamak için tereddüt ediyorum, diyelim, .bash_profileçünkü bu pam buna dikkat etmeli (çalışsa da).

Ben, tabii, ekleyebilir XDG_RUNTIME_DIRiçin env_keepde sudoers, ama bu sadece ne istiyorum olmadığı, sudoing kullanıcının çevreyi korumak olacaktır. Hedef kullanıcının ortamını istiyorum .

Gerçekten merak ettiğim şey, oturumun nasıl doğru bir şekilde oluşturulduğudur ssh, suya da değil sudo -i?

Bu sorunu Fedora 25 sistemimde kopyaladım.

Kaynak kodunda çok şüpheli bir durum buldum. https://github.com/systemd/systemd/blob/f97b34a/src/login/pam_systemd.c#L439 Normal sudodüşünülerek yazılmış gibi görünüyor ama değil sudo -u non-root-user.

machinectl shell --uid=non-root-user İstediğiniz gibi çalıştı.

systemd-run makinenin dokümantasyonundaki referansa rağmen istenildiği gibi çalışmadığı görülmüştür.

SELinux'u şu anda etkinleştirdiyseniz bazı machinectl komutları çalışmaz ve bu özel komutlar ben yapana kadar benim için çalışmadı setenforce 0. Ancak ben SELinux wrt istiyorum gibi machinectl çalışma almak için geçici çözümler çalışırken ortasındayım, bu yüzden benim machinectl shellzaman aşımına neden olan ne uğraştırmak mümkündür .

EDIT: Sanırım bu kod bu tartışmadan sonra tanıtıldı . Ve görünüşe göre su -/ sudo -içalışmak için yapılabilirdi, ama hiç kimse onu (hala) uygulamadı.

Gerçekten merak ettiğim şey, oturumun ssh ile nasıl doğru bir şekilde ayarlandığı, ancak su veya sudo -i ile nasıl ayarlanmadığı?

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

Maalesef "su", kullanıcı kimliklerini ve çok az sayıda diğer işlem kimlik bilgisini geçici olarak değiştirmek için bir araçtır. Tamamen yeni bir giriş oturumu açmak için bir araç değil. Yeni bir giriş oturumu çok iyi tanımlanmış, bozulmamış bir düzene sahiptir, başka bir oturumdan hiçbir şey miras almaz, ancak bu gerçekten "su" uid değişiklikleri için geçerli değildir: yürütme ortamının çoğu devralınır, sayısız ve açık değil yollar, örneğin MAC bağlamları, denetim bağlamları, grup grupları bağlamları, ad alanı bağlamları, zamanlama, zamanlayıcı ayrıntı düzeyi,…

Tamamen yeni bir oturum istiyorsanız, "machinectl login" ya da "machinectl shell" gibi bir şey kullanın, bu da tamamen temiz, bağımsız, ayırma ortamınızı alacaktır ve hiçbir gizli işlem özelliği onu aradığınız yerden sızıntı yapmaz.

Logind oturumları çoğunlukla denetim oturumu kavramına bağlıdır ve denetim oturumları "su" dan etkilenmez, aslında "mühürlenmiş" olarak tanımlanırlar, yani bir süreç bir kez bir oturuma girerse her zaman kalacaktır. çocuklarıyla da aynı şekilde olacak, yani yeni bir oturum almanın tek yolu PID 1'den (ya da benzer bir şeyden) hiçbir zaman bir oturumun parçası olmayan bir şey çıkarmaktır.

Ya da bunu farklı bir şekilde söylemek gerekirse: "su" ile çağırdığınız şeyler "loginctl" içinde gayet iyi görünecektir, ancak orijinal oturumunuzun bir parçası olarak kalır, başlangıçta giriş yaptınız. Orijinal oturumun kimliğinde "loginctl status" komutunu çağırarak bunu doğrulayabilirsiniz (ki bu, echo $ XDG_SESSION_ID ile görebilirsiniz)