Có an toàn để chown `/ usr / local` không?

Tôi biết những gì /usr/localdành cho - cài đặt phần mềm cho máy cục bộ. Theo mặc định, rootsở hữu thư mục. Điều này có nghĩa là để cài đặt ở đó, bạn cần sử dụng sudo. Đối với máy một người dùng hoặc nhà phát triển, điều này có vẻ như việc sử dụng thêm lệnh không cần thiết. Do đó, câu hỏi của tôi - có an toàn cho tôi để sở hữu /usr/localkhông?

Ví dụ: Homebrew cho OS X "Just Works" vì họ sở hữu /usr/localvà cài đặt phần mềm của họ ở đó một cách an toàn mà không cần sử dụng sudo.

Ngoài ra, nếu bạn đã cài đặt phần mềm được biên dịch cục bộ /usr/local, phần mềm hiện cần root để tự sửa đổi hoặc cài đặt plugin. Điều này có vẻ không an toàn - tôi muốn chỉ sử dụng sudokhi tôi biết CHÍNH XÁC những gì sẽ xảy ra.

Ý kiến?

Tôi không thể khuyên bạn nên trở thành chủ sở hữu của /usr/local; trong hầu hết các tình huống, nó có thể kém an toàn hơn so với sử dụng sudo.

Câu hỏi của bạn cho thấy hai lý do bạn có thể muốn chown /usr/local.

Đầu tiên là tránh phải sử dụng sudođể cài đặt phần mềm. Điều này có thể đọc cho một số (ví dụ như tác giả của câu trả lời này ) cho biết bạn muốn làm việc một cách hiệu quả, tiết kiệm hoặc các tổ hợp phím cần thiết để gõ sudovà nhập mật khẩu của bạn. Nhưng có lẽ khi bạn nói "không cần thiết", thay vào đó bạn đang đề cập đến nguyên tắc đặc quyền tối thiểu :

Theo mặc định, rootsở hữu thư mục. Điều này có nghĩa là để cài đặt ở đó, bạn cần sử dụng sudo. Đối với máy một người dùng hoặc nhà phát triển, điều này có vẻ như việc sử dụng thêm lệnh không cần thiết

Tôi thường nghe / đọc những người phản đối / phàn nàn dọc theo dòng chữ "Tôi là người duy nhất sử dụng hệ thống này, vì vậy tôi không cần phải sử dụng sudovà nhập mật khẩu." Đối với những độc giả có quan điểm đó và vì nó có liên quan ở đây, chúng ta hãy tự nhắc nhở mình về một lý do bảo mật cơ bản để root để sở hữu mọi thứ.

Hầu hết các tệp chương trình được cài đặt trên hệ thống Ubuntu có chế độ tệp 755 hoặc ký hiệu tượng trưng rwxr-xr-x, có nghĩa là bất kỳ người dùng hoặc chương trình nào cũng có thể thực thi chúng , nhưng chỉ chủ sở hữu của tệp, gốc, mới có thể sửa đổi chúng. (Về mặt kỹ thuật, điều này cũng yêu cầu không ai ngoài root có wquyền trên thư mục chứa chúng, vì vậy những người dùng khác không thể xóa hoặc di chuyển chúng.)

Điều này có nghĩa là bạn, người dùng khiêm tốn, có thể thực hiện bất kỳ chương trình nào. Nếu bạn cố gắng sử dụng một chương trình để làm điều gì đó mà bạn không được phép làm, như thực hiện thao tác ghi trên tệp do root sở hữu, nó sẽ báo lỗi. Điều này tạo ra một lỗi đánh máy trong một số lệnh, ứng dụng lỗi hoặc mã độc, ít có khả năng làm rối hệ thống của bạn - trừ khi nó chạy bằng root, nó sẽ không được phép làm như vậy. Điều này đặc biệt hữu ích khi chạy các chương trình tương tác với internet.

Nếu bạn chown /usr/local, bất kỳ chương trình nào chạy với đặc quyền của bạn đều có thể ghi các tệp ở đó, sau này có thể được thực thi dưới quyền root vì một số lý do, chẳng hạn như bằng cách thay thế một lệnh khác có cùng tên. /usr/local/binlà trong mặc định $PATH, và trong sudo's secure_path, và nó đi kèm trước khi các địa điểm khác trong cả hai. Vì vậy, nếu tôi có hai thực thi

/usr/local/bin/chown
/bin/chown

khi tôi thực hiện sudo chown ..., các chowntrong /usr/local/binsẽ được thực thi .

Nhưng có lẽ bạn đã biết tất cả điều đó, vì lý do thứ hai của bạn là về bảo mật:

Ngoài ra, nếu bạn đã cài đặt phần mềm được biên dịch cục bộ /usr/local, phần mềm hiện cần root để tự sửa đổi hoặc cài đặt plugin. Điều này có vẻ không an toàn - tôi muốn chỉ sử dụng sudokhi tôi biết CHÍNH XÁC những gì sẽ xảy ra.

_{Trong trường hợp cần phải đề cập đến vấn đề này ở đây, thì hoàn toàn đúng (theo FHS dù sao) để cài đặt phần mềm được biên dịch cục bộ /usr/local, nhưng việc biên dịch chính nó nên được thực hiện ở đâu đó trong $HOME, mà không sudo, cho đến bước cuối cùng khi bạn nhập sudo make installhoặc tương đương.}

Tôi nghĩ rằng bạn đang đề xuất rằng bằng cách chạy một chương trình được cài đặt /usr/localvới tư cách là chủ sở hữu không có đặc quyền của nó, bạn có thể sử dụng các lỗi cấp phép cụ thể được ném khi nó cố cập nhật để thấy rằng nó đang cố gắng sửa đổi một số vị trí hệ thống tệp khác không thuộc sở hữu của bạn theo cách bạn không muốn, để bạn có thể ngăn nó làm như vậy.

Điều này có thể hữu ích. Hàm ý là bạn tin tưởng chương trình sẽ làm bất cứ điều gì nó thích bên trong /usr/local, nhưng không phải nơi nào khác. Nếu nó yêu cầu quyền nâng cao, bạn có thể từ chối cho phép cập nhật hoặc gỡ cài đặt nó. Điều đó có ý nghĩa với tôi. Nhưng tôi nghĩ rằng cố gắng sử dụng /usr/localnhư một loại hộp cát theo cách này có lẽ không phải là một ý tưởng tốt, hoặc ít nhất nó không phải là giải pháp an toàn nhất. Đây không phải là một vị trí biệt lập đúng cách ( /optbị cô lập hơn một chút, vì nó không có trong mặc định $PATH). Chương trình có thể viết hoặc xóa một cái gì đó /usr/localđể gây hại. Các chương trình khác (có khả năng được viết kém) mà bạn chạy có thể viết và thực thi mã ở đó mà bạn không biết.

Nếu bạn lo lắng về việc cho phép chương trình tự cập nhật một cách an toàn, có lẽ bạn nên tìm giải pháp thay thế (cụ thể là chương trình, ví dụ như với python, hoặc bạn có thể tìm kiếm một cách thực hiện nhanh hoặc tương tự phù hợp với nhu cầu của mình hoặc sử dụng chứa hoặc VM để kiểm tra phần mềm có khả năng không an toàn) trước khi để lộ vị trí hệ thống (thậm chí là tương đối người dùng) được ghi bởi các chương trình được chạy bởi người dùng bình thường. Điều đó đối với tôi dường như có những tác động không thể đoán trước khi cho phép các chương trình nâng cao quyền tạm thời với sudo.

Đó là bất thường mà /usr/localkhông thuộc sở hữu của root. Nhưng bạn có thể thay đổi chủ sở hữu như bạn muốn.

Nhưng tôi khuyên bạn nên đảm bảo rằng /usr/local/sbinvẫn thuộc sở hữu của rootmình để tránh sự cố bảo mật. Các lệnh ở đây thường được gọi chỉ bằng root.

Đối với phần mềm chỉ bạn cần, sử dụng thư mục nhà của bạn thay vì /usr/local.

Thay vì thay đổi quyền sở hữu /usr/localhoặc phải chạy các lệnh dưới quyền root khi bạn không muốn, bạn chỉ nên định cấu hình các bản dựng để chúng cài đặt trong thư mục chính của bạn thay vì /usr/local. Điều này giải quyết tất cả các vấn đề tiềm ẩn với việc thay đổi quyền sở hữu /usr/local, bao gồm cả cách thức binvà sbinthư mục con của nó nằm trong rootđường dẫn của nó.

Nếu bạn cần cho phép người dùng khác chạy phần mềm của mình, bạn có thể cấp cho họ quyền truy cập. Trên thực tế, họ có thể sẽ có thể, vì theo mặc định, thư mục chính của bạn có quyền đọc và thực thi quyền truy cập . (Nếu bạn không muốn điều đó, bạn có thể thay đổi nó khá dễ dàng, chỉ bằng cách sử dụng chmodtrên bất kỳ tệp hoặc thư mục nào bạn muốn đặt ở chế độ riêng tư và cũng có thể thay đổi umask.)

Với phần mềm được cài đặt trong thư mục nhà của bạn, các tệp nhị phân sẽ đi vào /usr/local/binthay vào đó sẽ đi vào . Bạn sẽ nhận được các thư mục con khác trong thư mục chính của bạn tương ứng với các thư mục con của phần mềm mà bạn cài đặt cần. Điều này thường sẽ tự động xảy ra khi bạn cài đặt phần mềm từ mã nguồn./home/username/bin/usr/local

Cấu hình bản dựng của bạn

Hầu hết các phần mềm bạn xây dựng từ mã nguồn có một bước nơi bạn chạy:

./configure

Đối với phần lớn các phần mềm có configuretập lệnh có thể chạy như vậy, nó mặc định cấu hình bản dựng để cài đặt bên trong /usr/localkhi cuối cùng bạn chạy sudo make installđể cài đặt nó. Lý do là nó hoàn toàn tương đương với việc chạy:

./configure --prefix=/usr/local

Để định cấu hình bản dựng để cài đặt trong thư mục chính của bạn, hãy sử dụng thay thế này:

./configure --prefix="$HOME"

Trong thực tế, trong Ubuntu, các đường dẫn thư mục chính không chứa khoảng trắng, khoảng trắng khác hoặc các ký tự khác sẽ được xử lý đặc biệt bởi shell như *vậy, trừ khi bạn thiết lập tài khoản người dùng của mình khá kỳ lạ, bạn chỉ cần gõ:

./configure --prefix=$HOME

(Tuy nhiên, tôi không khuyên bạn nên tập thói quen viết tập lệnh . Ngoài ra, trên một số HĐH khác - chẳng hạn như macOS - việc các đường dẫn đến thư mục chính của người dùng có chứa khoảng trắng sẽ không phổ biến.)

Hoặc nếu bạn thích, bạn có thể gõ đường dẫn thư mục nhà đầy đủ của mình:

./configure --prefix=/home/username

(Tất nhiên, thay thế usernamebằng tên người dùng thực tế của bạn. Nếu vì lý do nào đó, thư mục chính của bạn không có /homethì bạn sẽ phải điều chỉnh cho phù hợp.)

Cài đặt bản dựng của bạn

Sau khi bạn chạy make, bạn có thể quen với việc chạy sudo make install, nhưng khi bạn cài đặt trong thư mục chính của mình, bạn không cần phải chạy nó dưới quyền root, vì vậy bạn có thể - và nên --omit sudo. Chỉ cần chạy:

make install

Tương tự, đối với phần mềm hỗ trợ uninstallmục tiêu:

make uninstall

Đây chính xác là những gì bạn đã yêu cầu ... chỉ trong thư mục nhà của bạn, không phải /usr/local.

Chạy chương trình của bạn

Có lẽ các binthư mục con của thư mục chính của bạn là một trong hai:

• đã có trong $PATH, hoặc
• sẽ ở trong bạn $PATHnếu bạn chỉ cần đăng xuất và đăng nhập lại.

Lý do là .profiletệp trong thư mục chính của bạn, chứa các lệnh chạy khi bạn đăng nhập, mặc định chứa tệp này cho các tài khoản người dùng được tạo trong hầu hết các phiên bản Ubuntu (bao gồm cả tài khoản quản trị viên ban đầu được tạo khi bạn cài đặt HĐH):

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

Mã đó chạy khi bạn đăng nhập (vì nó vào .profile) và đặt binthư mục cá nhân của bạn $PATH chỉ khi nó tồn tại vào thời điểm đó. Đó là lý do tại sao bạn có thể cần phải đăng xuất và đăng nhập lại.

Các bản phát hành cũ hơn như Ubuntu 14.04, cũng như các bản phát hành mới hơn như Ubuntu 17.10, đi kèm với điều đó. Tuy nhiên, Ubuntu 16.04, có lẽ là bản phát hành phổ biến nhất kể từ bài viết này, thay vào đó:

# set PATH so it includes user's private bin directories
PATH="$HOME/bin:$HOME/.local/bin:$PATH"

Điều đó chỉ đơn giản là thêm binthư mục con của thư mục chính của bạn --- cũng như .local/binthư mục con - vào thư mục của bạn $PATH, mà không kiểm tra xem các thư mục đó có thực sự tồn tại không. Vì vậy, nếu bạn sử dụng 16.04 hoặc nếu bạn đã nâng cấp từ hệ thống 16.04 khi tài khoản người dùng của bạn được tạo, thì binthư mục con của thư mục chính của bạn có khả năng đã có trong của bạn $PATH.

.profileTập tin của bạn được sao chép từ /etc/skelthư mục khi tài khoản người dùng của bạn được tạo. Nếu tài khoản người dùng của bạn được tạo trên một bản phát hành Ubuntu cũ hơn, thì nó đã có phiên bản .profileđó và nó không bị thay đổi - đối với tài khoản người dùng của bạn - bằng cách nâng cấp lên bản phát hành gần đây hơn.

Khi binthư mục con của thư mục chính của bạn nằm trong bạn $PATH, bạn sẽ có thể chạy các chương trình có tệp thực thi được cài đặt ở đó chỉ bằng cách nhập tên của chúng, giống như bạn có thể làm với các chương trình được cài đặt bởi trình quản lý gói của Ubuntu hoặc được cài đặt bên trong /usr/local.

các .localTùy chọn

Bạn có thể nhận thấy rằng .profiletệp mặc định cho tài khoản người dùng được tạo trong một số bản phát hành Ubuntu, bao gồm cả 16.04 như được mô tả ở trên, không chỉ thêm $HOME/binvào đường dẫn của bạn mà còn $HOME/.local/bin. Nếu bạn .profilekhông thêm nó, nhưng bạn muốn nó, thì bạn chỉ cần chỉnh sửa nó.

Mặc dù thường được sử dụng để lưu trữ cài đặt và dữ liệu được lưu trong bộ nhớ cache , bạn cũng có thể cài đặt phần mềm bên trong .localthư mục con của thư mục chính. Bạn nên cảm thấy không bị ràng buộc khi làm như vậy, vì từ quan điểm khả năng sử dụng và bảo mật, --prefix="$HOME/.local"tương tự như --prefix="$HOME".

Hãy nhớ rằng các tệp và thư mục bắt đầu .không được hiển thị theo mặc định trong các trình duyệt tệp đồ họa (sử dụng Ctrl+ Hđể bỏ ẩn và phục hồi chúng) hoặc bằng lslệnh (truyền -Ahoặc -acờ để hiển thị chúng). Đây có thể không phải là những gì bạn muốn, hoặc nó có thể là chính xác những gì bạn muốn. Đây là một vấn đề sở thích cá nhân.

Tuy nhiên, tôi đã quan sát thấy rằng một số trình quản lý gói dựa trên nguồn tự động xây dựng và cài đặt phần mềm trong thư mục chính của một người sử dụng $HOME/.local. Tôi thực sự không biết mức độ phổ biến của nó - Tôi hy vọng sẽ điều tra thêm và cập nhật câu trả lời này - nhưng bạn có thể chỉ muốn sử dụng $HOMEcho những thứ bạn biên dịch thủ công. Bằng cách đó, nó sẽ rõ ràng nơi mọi thứ đến từ. Và nếu có va chạm, phần mềm vẫn có khả năng cùng tồn tại chấp nhận được.

Bạn cũng có thể cố tình cài đặt một số phần mềm trong $HOME/.localvà phần mềm khác $HOME. Tuỳ bạn. Bất kỳ binthư mục nào xuất hiện đầu tiên trong $PATHbiến môi trường của bạn là một lệnh mà một lệnh sẽ chạy từ đó, trong trường hợp các lệnh cùng tên tồn tại trong cả hai.

Tín dụng đến Zanna và Videonauth vì đã chỉ ra lỗi trong phiên bản trước của câu trả lời này, liên quan đến bản phát hành Ubuntu nào có mã mặc định .profilevà giúp tôi sửa lỗi (xem thêm tại đây ).

Nếu sudo là một sự bất tiện như vậy thì chỉ cần cập nhật / etc / sudoers để bạn không phải nhập mật khẩu khi chạy sudo. Tôi tin rằng đó là một giải pháp tốt hơn so với việc thay đổi chủ sở hữu của / usr / local.