Tại sao sudo -i không đặt XDG_RUNTIME_DIR cho người dùng đích?

XDG_RUNTIME_DIRlà cần thiết systemctl --userđể làm việc.

Tôi đã thiết lập máy chủ Ubuntu 16.04 để chạy các phiên người dùng systemd. Bây giờ, khi cố gắng quản trị chúng, tôi thấy rằng khi thay đổi người dùng thông qua sudo -u $user -ihoặc thậm chí su - $user, môi trường không được XDG_RUNTIME_DIRthiết lập, ngăn systemctl --userkhông cho hoạt động. Tuy nhiên, khi tôi sshvào thẳng người dùng đó, nó được đặt chính xác.

Nếu tôi hiểu tài liệu chính xác, điều này nên được đặt libpam-systemdkhi tạo phiên người dùng. Các lát cắt người dùng được bắt đầu một cách chính xác, như thư mục mà XDG_RUNTIME_DIRđiểm ( /run/users/$uid) sẽ tồn tại. Tôi do dự chỉ cần mã hóa cứng .bash_profile, vì, điều đó có vẻ như hacky (mặc dù đang hoạt động), khi pam nên chăm sóc nó.

Tôi có thể, tất nhiên, thêm XDG_RUNTIME_DIRvào env_keeptrong sudoers, nhưng điều đó sẽ chỉ bảo vệ môi trường của người dùng sudoing, mà không phải là những gì tôi muốn. Tôi muốn môi trường của người dùng mục tiêu .

Tuy nhiên, điều tôi thực sự thắc mắc là làm thế nào mà phiên được thiết lập chính xác với ssh, nhưng không phải với suhay sudo -i?

Tôi đã sao chép vấn đề này trên hệ thống Fedora 25 của mình.

Tôi tìm thấy một điều kiện rất đáng ngờ trong mã nguồn. https://github.com/systemd/systemd/blob/f97b34a/src/login/pam_systemd.c#L439 Có vẻ như nó được viết với sudoý nghĩ bình thường nhưng không phải vậy sudo -u non-root-user.

machinectl shell --uid=non-root-user làm việc như bạn yêu cầu

systemd-run đã không xuất hiện để làm việc như mong muốn, mặc dù tham chiếu đến nó trong tài liệu machinectl.

Một số lệnh machinectl không hoạt động nếu bạn đã bật SELinux vào lúc này và các lệnh cụ thể này không hoạt động với tôi cho đến khi tôi thực hiện setenforce 0. Tuy nhiên, tôi đang cố gắng giải quyết các vấn đề để làm cho machinectl hoạt động như tôi muốn nó để viết SELinux, vì vậy có thể vấn đề của tôi là nguyên nhân gây ra machinectl shellthời gian chờ.

EDIT: Tôi nghĩ rằng mã này đã được giới thiệu sau cuộc thảo luận này . Và rõ ràng su -/ sudo -icó thể được thực hiện để làm việc, nhưng không ai đã thực hiện nó (vẫn).

Tuy nhiên, điều tôi thực sự thắc mắc là làm thế nào mà phiên được thiết lập chính xác với ssh, nhưng không phải với su hay sudo -i?

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

Xin lỗi, nhưng "su" là một công cụ để thay đổi danh tính người dùng và rất ít thông tin xác thực quy trình khác tạm thời. Đây không phải là một công cụ để mở một phiên đăng nhập hoàn toàn mới. Một phiên đăng nhập mới có một thiết lập nguyên sơ, được xác định rõ ràng, không kế thừa bất cứ thứ gì từ bất kỳ phiên nào khác, nhưng đây thực sự không phải là trường hợp thay đổi "su": hầu hết môi trường thực thi được kế thừa, trong rất nhiều và không rõ ràng cách, ví dụ bối cảnh MAC, bối cảnh kiểm toán, bối cảnh nhóm, bối cảnh không gian tên, lập lịch, độ chi tiết của bộ đếm thời gian, chế độ

nếu bạn muốn có một phiên hoàn toàn mới, hãy sử dụng một cái gì đó như "đăng nhập machinectl" hoặc "machinectl shell", điều này thực sự sẽ mang lại cho bạn một môi trường tách biệt, độc lập, hoàn toàn sạch sẽ, không có thuộc tính quy trình ẩn nào bị rò rỉ từ nơi bạn gọi nó vào đó.

các phiên logind chủ yếu bị ràng buộc với khái niệm phiên kiểm toán và các phiên kiểm toán vẫn không bị ảnh hưởng bởi "su", trên thực tế chúng được xác định là "niêm phong", tức là theo cách mà nếu một quy trình được nhập vào một phiên, nó sẽ luôn duy trì với nó, và con cái của nó cũng vậy, tức là cách duy nhất để có được một phiên mới là loại bỏ thứ gì đó ra khỏi PID 1 (hoặc một cái gì đó tương tự) chưa bao giờ là một phần của phiên.

Hoặc để nói điều này khác đi: những thứ bạn gọi qua "su" sẽ hiển thị tốt trong "logincl", tuy nhiên, nó vẫn là một phần của phiên ban đầu của bạn, ban đầu bạn đã đăng nhập. Bạn có thể xác minh rằng bằng cách gọi "trạng thái logincl" trên ID của phiên ban đầu (mà bạn có thể thấy qua echo $ XDG_SESSION_ID)