Tình huống: Khi Git trở nên quá thận trọngMọi chuyện diễn ra trong nháy mắt. Bạn kích hoạt một tiến trình build bên trong container Docker hoặc một pipeline CI/CD, mong đợi một quá trình triển khai suôn sẻ. Mã nguồn của bạn đã được mount, môi trường đã sẵn sàng, và bạn chạy một lệnh tiêu chuẩn như git status. Thay vì danh sách tệp, Git dừng hoạt động kèm theo một cảnh báo bảo mật:
fatal: detected dubious ownership in repository at '/workspace'
Đây không phải là một lỗi ngẫu nhiên. Đây là một tính năng bảo mật được giới thiệu trong Git v2.35.2 để vá lỗ hổng CVE-2022-24765. Lỗ hổng này có thể cho phép kẻ xấu thực thi mã bằng cách đặt một thư mục .git độc hại trong một thư mục chia sẻ. Giờ đây, Git từ chối thao tác với bất kỳ kho lưu trữ (repository) nào mà người dùng hiện tại không sở hữu thư mục .git.
Tại sao điều này xảy raGit hiện thực hiện kiểm tra quyền sở hữu nghiêm ngặt. Trong một thiết lập Docker điển hình, bạn có thể mount một thư mục dự án cục bộ thuộc sở hữu của người dùng máy chủ (thường là UID 1000) vào một container nơi tiến trình chạy dưới quyền root (UID 0). Vì các UID không khớp nhau, Git giả định rằng kho lưu trữ này không đáng tin cậy. Nó chặn tất cả các hoạt động để ngăn chặn các hành vi khai thác tiềm ẩn trong môi trường chia sẻ.
Giải pháp 1: Sửa lỗi có mục tiêuCách chính xác nhất để giải quyết vấn đề này là thông báo rõ ràng cho Git rằng một thư mục cụ thể là an toàn. Cách tiếp cận này giúp duy trì tính bảo mật cho mọi thứ khác trong khi vẫn gỡ bỏ rào cản cho dự án của bạn. Hãy chạy lệnh này bên trong container hoặc runner của bạn:
git config --global --add safe.directory /workspace
Hãy đảm bảo bạn thay thế /workspace bằng đường dẫn chính xác được hiển thị trong thông báo lỗi của bạn. Lệnh này cập nhật tệp .gitconfig toàn cục của bạn, tạo ra một ngoại lệ lâu dài cho đường dẫn đó.
Giải pháp 2: Giải pháp "Tổng quát" cho CI/CDCác pipeline tự động thường sử dụng các đường dẫn động hoặc nhiều submodule. Trong một môi trường tạm thời như GitHub Actions runner, bạn có thể không muốn đưa từng đường dẫn vào danh sách trắng (whitelist) một cách thủ công. Nếu môi trường được cô lập và bạn tin tưởng mã nguồn, hãy sử dụng cách sửa lỗi bằng ký tự đại diện (wildcard):
git config --global --add safe.directory '*'
Sử dụng thận trọng. Chỉ áp dụng ký tự đại diện '*' trong các môi trường cô lập, tồn tại ngắn hạn. Tuyệt đối không chạy lệnh này trên máy chủ production dùng chung có nhiều người dùng, vì nó sẽ vô hiệu hóa hoàn toàn việc kiểm tra bảo mật.
Giải pháp 3: Triển khai trong cấu hình Docker và CI### Tối ưu hóa DockerfileTránh việc sửa lỗi thủ công bằng cách tích hợp cấu hình vào image của bạn. Điều này đảm bảo mọi container được khởi tạo từ image đều sẵn sàng cho các thao tác Git ngay lập tức:
FROM alpine:3.18
RUN apk add --no-cache git
# Phê duyệt trước đường dẫn workspace phổ biến để tránh lỗi sở hữu
RUN git config --global --add safe.directory /app
WORKDIR /app
COPY . .
Tối ưu hóa GitHub ActionsNếu các script tùy chỉnh hoặc action của bên thứ ba bị lỗi, hãy chèn một bước cấu hình vào giai đoạn đầu của workflow. Chỉ mất chưa đầy một giây để chạy và giúp ngăn chặn các lỗi phát sinh sau đó:
- name: Đánh dấu workspace là an toàn
run: git config --global --add safe.directory ${GITHUB_WORKSPACE}
- name: Tạo metadata cho bản build
run: git describe --tags --always
Giải pháp 4: Thay đổi quyền sở hữu tệpBạn cũng có thể điều chỉnh quyền sở hữu tệp khớp với người dùng hiện tại. Đây là "cách của Linux" để giải quyết vấn đề mà không cần thay đổi cài đặt Git. Bên trong container, hãy thực thi:
chown -R $(id -u):$(id -g) /workspace
Hãy cân nhắc kỹ trước khi sử dụng cách này trên các volume được mount. Vì Docker chia sẻ hệ thống tệp cơ sở, việc thay đổi quyền sở hữu bên trong container cũng sẽ thay đổi nó trên máy chủ của bạn. Điều này thường dẫn đến lỗi "Permission Denied" (Từ chối quyền truy cập) khi bạn quay lại IDE hoặc trình soạn thảo văn bản của mình.
Xác minh kết quảXác nhận rằng Git đã ghi nhận các thay đổi của bạn bằng cách liệt kê tất cả các thư mục an toàn đang hoạt động. Chạy lệnh sau:
git config --global --get-all safe.directory
Nếu đầu ra hiển thị chính xác đường dẫn của bạn hoặc ký tự *, các lệnh git status hoặc git fetch của bạn sẽ hoạt động bình thường. Cách sửa lỗi này sẽ duy trì hiệu lực miễn là tệp ~/.gitconfig còn tồn tại trong môi trường của bạn.