Tại sao các biến PATH khác nhau khi chạy qua sudo và su?

Trên máy ảo fedora của tôi, khi chạy bằng tài khoản người dùng của tôi, tôi có /usr/local/bintrong đường dẫn của mình:

[justin@justin-fedora12 ~]$ env | grep PATH
 PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin

Và tương tự như vậy khi chạy su:

[justin@justin-fedora12 ~]$ su -
Password: 
[root@justin-fedora12 justin]# env | grep PATH
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/justin/bin

Tuy nhiên, khi chạy qua sudo, thư mục này không nằm trong đường dẫn:

[root@justin-fedora12 justin]# exit
[justin@justin-fedora12 ~]$ sudo bash
[root@justin-fedora12 ~]# env | grep PATH
PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/sbin:/bin:/usr/sbin:/usr/bin

Tại sao đường dẫn sẽ khác khi chạy qua sudo?

Hãy nhìn vào /etc/sudoers. Tệp mặc định trong Fedora (cũng như trong RHEL, và cả Ubuntu và tương tự) bao gồm dòng này:

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

Điều này đảm bảo rằng đường dẫn của bạn sạch sẽ khi chạy nhị phân theo sudo. Điều này giúp bảo vệ chống lại một số mối quan tâm được lưu ý trong câu hỏi này . Nó cũng thuận tiện nếu bạn không có /sbinvà /usr/sbintrên con đường của riêng bạn.

Lệnh su -sẽ thực thi hồ sơ người dùng root và đảm nhận môi trường của người dùng đó bao gồm cả đường dẫn, v.v. sudokhông làm điều đó.

Nếu bạn muốn sudocư xử như thế su -thì hãy sử dụng tùy chọn sudo -i [commandsẽ thực thi hồ sơ của người dùng

Nếu bạn muốn su -cư xử như vậy sudothì đừng sử dụng dấu gạch nối - chỉ cần sử dụngsu [command]

Bạn có thể kiểm tra tại sao (nó khác) bằng cách chạy sudo sudo -V.

Ví dụ trên Linux chạy:

$ sudo sudo -V | grep PATH
Value to override user's $PATH with: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

^{Lưu ý: Trên macOS / BSD, chỉ cần chạy : sudo sudo -V.}

Danh sách trên bị hạn chế do plugin chính sách bảo mật mặc định trong một số bản phân phối Linux.

Điều này được giải thích thêm trong man sudoers:

Nếu secure_pathtùy chọn được đặt, giá trị của nó sẽ được sử dụng cho PATHbiến môi trường.

secure_path- Đường dẫn được sử dụng cho mọi lệnh chạy từ sudo. Nếu bạn không tin tưởng những người chạy sudo có PATHbiến môi trường lành mạnh, bạn có thể muốn sử dụng biến này.

Một cách sử dụng khác là nếu bạn muốn có đường dẫn gốc của Google thì hãy tách biệt với đường dẫn người dùng của Google. Người dùng trong nhóm được chỉ định bởi exempt_grouptùy chọn không bị ảnh hưởng bởi secure_path. Tùy chọn này không được đặt theo mặc định.

Nếu đó là trường hợp, bạn có thể thay đổi điều đó bằng cách chạy sudo visudovà chỉnh sửa tệp cấu hình và sửa đổi secure_path(thêm đường dẫn bổ sung cách nhau :) hoặc thêm người dùng của bạn vào exempt_group(để bạn không bị ảnh hưởng bởi secure_pathcác tùy chọn).

Hoặc để vượt qua người dùng PATHtạm thời, bạn có thể chạy:

sudo env PATH="$PATH" my_command

và bạn có thể kiểm tra xem bằng cách:

sudo env PATH="$PATH" env | grep ^PATH

Xem thêm: Làm thế nào để sudobảo quản $PATH?

Lý do khác tại sao môi trường có thể khác sudo, vì bạn có thể env_resetbật tùy chọn trong sudoerstệp của mình . Điều này khiến các lệnh được thực thi với một môi trường mới, tối thiểu.

Vì vậy, bạn có thể sử dụng env_keeptùy chọn (không được khuyến nghị vì lý do bảo mật ) để bảo vệ các biến môi trường của người dùng của bạn:

Defaults        env_reset
Defaults        env_keep += "PATH PYTHONPATH"

Trong hầu hết các linux, bạn cài đặt các chương trình thông qua quản lý gói và nhận các bản cập nhật một cách thường xuyên. Nếu bạn cài đặt một cái gì đó phá vỡ quản lý gói, nó sẽ được cài đặt trong / usr / local / bin (ví dụ: hoặc ... / sbin, hoặc / opt) và không nhận được cập nhật thường xuyên.

Do đó, tôi đoán rằng các chương trình không được coi là an toàn và không được đặt vào gốc PATH theo mặc định.

Tôi đã tự mình thử điều này và tôi không thấy hành vi bạn đang thấy - đường dẫn của tôi vẫn giữ nguyên, vì vậy có thể cấu hình sudo của bạn khác. Nếu bạn kiểm tra man sudoersbạn sẽ thấy có một tùy chọn được gọi là secure_pathđặt lại PATH- có vẻ như tùy chọn này có thể đã được bật.

Bởi vì khi bạn sử dụng sudo bash, bashkhông hoạt động như một vỏ đăng nhập. Hãy thử lại với sudo bash -lvà bạn sẽ thấy kết quả tương tự như su -.

Nếu điều đó là đúng, thì sự khác biệt trong PATHsự dối trá trong các tập tin cấu hình: /etc/profile, ~/.bash_profile, ~/.bash_login, ~/.profileđược thực thi (theo thứ tự đó) cho một vỏ đăng nhập, khi ~/.bashrcđược thực hiện cho một lớp vỏ tương tác không đăng nhập.

Câu hỏi cũ, tôi biết, nhưng tôi đã vấp ngã ở đây chỉ vì tôi đang điều tra vấn đề chính xác này.

Vì một số lý do /usr/local/binchỉ có trong PATH khi trở thành root thông qua sudo su -. Khi sử dụng sudo -inó không có ở đó. Tất nhiên bây giờ tôi biết tôi có thể thêm nó vào / etc / sudoers, nhưng điều đó vẫn không giải thích được tại sao nó lại ở đó sau đó su -. Phần này của PATH đến từ đâu?

Sau rất nhiều lần grepping và tìm kiếm, tôi đã tìm thấy câu trả lời:

Đường dẫn mặc định chứa '/ usr / local / bin' thực sự được mã hóa cứng trong su (1).

Vì vậy, không có cấu hình pam, hồ sơ, bashrc hoặc bất cứ điều gì chịu trách nhiệm cho việc chọn lọc thêm phần tử này. Nó đã luôn ở đó khi sutiếp quản. Và vì sudohoàn toàn không gọi sunhưng sử dụng cấu hình của chính nó, nó đã bị mất sausudo -i

Tôi thấy điều này là đúng trên RHEL6 và RHEL7. Tôi đã không kiểm tra bất kỳ phiên bản hoặc phân phối khác.