4.1.4

4.1.4 tiếp nối bản vá nóng thư 4.1.3. Bản này sửa những gì mục hạn chế đã biết của 4.1.3 hứa sẽ sửa trong 4.1.4, khắc phục các phát hiện về bộ nhớ đệm dùng chung trong đợt kiểm tra bảo mật 4.1.3, và làm cho quy trình cập nhật và cài đặt báo lỗi rõ ràng thay vì im lặng.

Ghi chú nâng cấp và thay đổi hành vi​

• Các trang WordPress do panel cài đặt từ phiên bản 3.9.6 đến 4.1.3 nay lưu khóa bảo mật trong wp-config.php thay vì trong cơ sở dữ liệu. Người dùng đang đăng nhập trên các trang này sẽ bị đăng xuất một lần sau khi cập nhật và cần đăng nhập lại. Trình cài WordPress của panel để hở chú thích đứng trước tám khóa (AUTH_KEY đến NONCE_SALT), nên các khóa nó ghi nằm trong chú thích và WordPress tự sinh khóa riêng rồi lưu trong cơ sở dữ liệu, nơi bất kỳ ai đọc được cơ sở dữ liệu (lỗ hổng SQL injection của một plugin, một bản sao lưu bị lộ) đều có thể giả mạo cookie đăng nhập. Bản cập nhật chạy hitechcloudcli websites-wp_install heal-salts --once một lần: chỉ tệp wp-config.php mang đúng khối do panel ghi mới được ghi lại, dưới quyền tài khoản, với khóa mới, và các khóa WordPress đã lưu trong cơ sở dữ liệu bị xóa. Khối khóa do khách hàng tự viết, hoặc khối mẫu của WordPress, được giữ nguyên; tệp wp-config.php mà tài khoản không ghi được sẽ bị bỏ qua và được báo lại, không bao giờ bị đổi quyền để ghi được. Bản cập nhật liệt kê từng trang WordPress mà nó không sửa được, theo đường dẫn tệp wp-config.php, và chỉ hiện dấu thành công khi mọi trang đã được sửa; trang bị bỏ qua sẽ được thử lại ở lần cập nhật sau. (hitechcloudcli#471, #472, #473)
• Greylisting bắt đầu lại từ trống. Khóa greylist của rspamd nay dùng tiền tố hitechcloud.rspamd:rg, mà không thông tin đăng nhập bộ nhớ đệm của tài khoản nào chạm tới được, và greylisting đăng nhập vào bộ nhớ đệm bằng người dùng riêng hitechcloud.rspamd. Lịch sử lưu dưới tiền tố mặc định rg của rspamd không còn được đọc, nên một người gửi đã được biết sẽ bị trì hoãn thêm một lần, trong thời gian trì hoãn greylist, rồi được cho qua như trước. Trên Ubuntu 22.04 (rspamd 3.1) và Debian 12 (rspamd 3.4) có bộ nhớ đệm được bảo vệ, greylisting vẫn tắt: rspamd trước 3.7 không đăng nhập được bằng tên người dùng, và nó không bao giờ được trao mật khẩu quản trị của bộ nhớ đệm. Lệnh sẽ nói rõ điều này; rspamd 3.7 trở lên khắc phục được. (hitechcloudcli#460, #467)
• Khóa bộ nhớ đệm của webmail chuyển sang dưới Webmail:. Bản cập nhật chuyển các khóa đang dùng của webmail sang tên mới và ghi mọi phiên đang mở vào chỉ mục phiên mới trước khi webmail khởi động lại, nên không ai bị đăng xuất. Trên máy chủ có tài khoản hosting đặt tên trùng một họ khóa cũ (ví dụ sess), các phiên cũ bị xóa thay vì được chuyển, vì tài khoản đó có thể đã ghi đè chúng, và mọi người dùng webmail phải đăng nhập lại. Các họ khóa cũ vẫn được cấp cho người dùng bộ nhớ đệm của webmail chỉ trong bản này; 4.1.5 sẽ gỡ bỏ chúng. (hitechcloudcli#469, hitechcloudmail#90)
• Khôi phục cơ sở dữ liệu chỉ dùng thông tin đăng nhập cơ sở dữ liệu của chính tài khoản (thay đổi hành vi). Mọi đường khôi phục (khôi phục tài khoản, bộ sao lưu và tác vụ sao lưu, nhập trang, Sao chép cơ sở dữ liệu) từ chối tệp ~/my.cnf hoặc ~/.my.cnf ghi root hoặc thông tin đăng nhập của tài khoản khác, đọc bản dump theo cùng quy tắc với Sao chép cơ sở dữ liệu, và chạy trình khách cơ sở dữ liệu dưới quyền tài khoản. Các tài khoản chuyển từ nền tảng container cũ mang theo tệp như vậy; bản cập nhật thay nó bằng thông tin đăng nhập của chính tài khoản (hitechcloudcli account own-db-login --all), cũng là cách sửa bằng tay. (hitechcloudcli#457, #468)
• Server > Databases trong 2087 thuộc về Super Admin (thay đổi hành vi). Trang này liệt kê mọi cơ sở dữ liệu và thông tin đăng nhập trên máy chủ, có thể ngắt kết nối và đổi giới hạn của các dịch vụ cơ sở dữ liệu; trước đây mọi quản trị viên được ủy quyền đều mở được. Nay quản trị viên được ủy quyền chỉ vào được khi Super Admin cấp quyền, trên cùng trang với quyền phpMyAdmin và pgAdmin; quyền này tắt cho đến khi được bật. (hitechcloudadmin#315)
• Token API tạo bằng một token không rộng hơn token đó (thay đổi hành vi). Token tạo qua POST /api/account/mcp bằng một token có sẵn hết hạn không muộn hơn token đó và bị giới hạn trong cùng các tính năng và địa chỉ hoặc ít hơn. Token do người đã đăng nhập tạo không bị ảnh hưởng. (HiTechCloud-Panel#1753)
• Sao chép cơ sở dữ liệu sang tài khoản khác hỏi những gì việc chuyển sang tài khoản đó hỏi (thay đổi hành vi). Tài khoản đích phải ở trạng thái tốt, không bị khóa và cho phép địa chỉ của người gọi theo danh sách cho phép của chính nó, và khi tài khoản đó có ứng dụng xác thực thì mã hiện tại phải được nhập trên biểu mẫu, đúng như khi chuyển sang nó. Tài khoản đích chỉ có yếu tố thứ hai là mã gửi qua e-mail sẽ bị từ chối. Mỗi khách hàng chỉ chạy một lần sao chép tại một thời điểm; lần khác bị từ chối cho đến khi lần trước xong. (HiTechCloud-Panel#1752, hitechcloudcli#453)
• Máy chủ có bộ nhớ đệm dùng chung không mật khẩu được nêu tên trong mỗi lần cập nhật. Máy chủ đã có tài khoản hosting khi được cài đặt giữ một bộ nhớ đệm mà mọi tài khoản cục bộ đều đăng nhập được với tư cách default. Mỗi lần cập nhật nay nói rõ điều đó cho từng phiên bản như vậy và chỉ cách xử lý. hitechcloudcli objectcache clients liệt kê các trình khách sẽ bị cắt nếu bảo vệ nó, và objectcache secure trước hết chuyển các bộ nhớ đệm đối tượng WordPress do panel quản lý sang thông tin đăng nhập bộ nhớ đệm riêng của từng tài khoản, nên bảo vệ một máy chủ như vậy không còn làm hỏng các trang WordPress của nó. (hitechcloudcli#466)

Mới​

• hitechcloudcli objectcache clients, objectcache rewire-wordpress [--account NAME] (mỗi lần cập nhật đều chạy) và objectcache wordpress-enable --account A --dir D, lệnh bật bộ nhớ đệm đối tượng của một trang WordPress mà không cần FLUSHDB, vốn bị từ chối với thông tin đăng nhập bộ nhớ đệm của tài khoản: chỉ các khóa của chính trang đó bị xóa, và tệp drop-in của plugin được đặt vào chỗ dưới quyền tài khoản. (hitechcloudcli#466)
• hitechcloudcli account own-db-login [--all|<user>], lệnh tạo cho tài khoản một tệp my.cnf ghi thông tin đăng nhập cơ sở dữ liệu của chính nó; bản cập nhật chạy lệnh này. (hitechcloudcli#457)
• 2087: REST API cho khách hàng (/api/customers: liệt kê, tạo, xem, xóa, liên kết và hủy liên kết tài khoản), cùng cột Customer và bộ lọc trên trang Users. (hitechcloudadmin#316)

Đã sửa​

• Mỗi lần panel khởi động lại, và do đó mỗi lần cập nhật, đều đăng xuất mọi người dùng webmail. Từ 4.0.8, mỗi khi khởi động panel xóa bộ nhớ đệm Redis bằng cách xóa mọi khóa trên phiên bản dùng chung, trừ phiên của chính panel (session:*). Phiên bản đó còn chứa phiên, giới hạn tần suất và bộ chống phát lại của webmail, cùng các khóa riêng của mọi tài khoản hosting như bộ nhớ đệm đối tượng WordPress. Tất cả đều bị xóa mỗi lần khởi động lại. Nay panel chỉ xóa các giá trị ghi nhớ của chính nó, dưới hitechcloud_cache_, bằng SCAN MATCH trên tiền tố đó. Phiên webmail, chỉ mục phiên webmail của 4.1.4 và khóa của các tài khoản được giữ qua bản cập nhật. (HiTechCloud-Panel#1775)
• Các thao tác WordPress trong 2083 (ví dụ bật hoặc tắt bộ nhớ đệm đối tượng Redis) lỗi 500 Could not open input file: /etc/hitechcloud/wordpress/wp-cli.phar sau mọi lần cập nhật hoặc sửa chữa. wp-cli chạy dưới quyền tài khoản, và từ 4.0.4 các bản cập nhật đóng /etc/hitechcloud với các tài khoản. Trình cài đặt không còn đặt bản wp-cli gốc ở đó; bản cập nhật đổi tên bản gốc tìm thấy thành wp-cli.phar.stock-disabled (không bao giờ xóa) khi đã xác nhận /usr/local/bin/wp hoạt động, và giữ nguyên bản riêng của người vận hành kèm cảnh báo. 2083, CLI và trình quét trang dùng /usr/local/bin/wp, rồi wp trên đường dẫn, rồi bản tải về lưu trong /var/cache/hitechcloud/toolkit, không bao giờ dùng đường dẫn dưới /etc/hitechcloud; Composer được tìm theo cùng cách. Không còn cần cách xử lý tạm của 4.1.3. (hitechcloudcli#470, HiTechCloud-Panel#1772)
• Cài đặt WordPress có thể thất bại với lỗi cú pháp PHP. Khóa được sinh có chứa */ đóng chú thích quanh các khóa ngay giữa giá trị. Nay khóa được sinh không có * hay /. (hitechcloudcli#471)
• Bản cập nhật bị gián đoạn có thể được ghi nhận là hoàn tất trước khi các dịch vụ được khởi động lại (một hạn chế đã biết của 4.1.3). Các tiến trình cũ tiếp tục phục vụ trên tệp mới và mọi lần chạy sau đều báo "No update needed". Nay bản cập nhật được đánh dấu chưa hoàn tất cho đến khi các lần khởi động lại được thực hiện, nên lần chạy kế tiếp làm lại bản cập nhật, cùng các lần khởi động lại còn nợ. (hitechcloudcli#450)
• Bản cập nhật báo panel đang chạy trong khi không ai đăng nhập được. Bước kiểm tra sau khi panel khởi động lại chỉ hỏi /healthz và /login, vốn trả lời được dù không có bộ nhớ đệm dùng được. Nay nó còn đăng nhập vào bộ nhớ đệm đúng như engine của panel, và nếu bị từ chối thì bản cập nhật thất bại, nêu lệnh hitechcloudcli objectcache panel-login. Trong trường hợp đó trình cài đặt kết thúc với dòng cảnh báo "NOBODY CAN SIGN IN TO THE HOSTING PANEL YET" kèm cách sửa, và multiweb status tiếp tục báo điều này. (hitechcloudcli#451, #465)
• Gửi thư từ webmail thất bại trên máy chủ có tên máy phân giải ra địa chỉ riêng (sau NAT, trong container, hoặc được ánh xạ trong /etc/hosts; một hạn chế đã biết của 4.1.3). Bộ chặn kết nối ra ngoài của webmail nay miễn trừ đúng máy chủ thư của chính máy chủ này, trên các cổng thư tiêu chuẩn, ở chế độ panel; mọi máy chủ khác vẫn được kiểm tra như trước. (hitechcloudmail#91)
• webmail update chỉ giữ REDIS_URL của webmail khi chính trình khách của webmail đăng nhập được bằng nó, được kiểm tra theo cách trình khách đó đăng nhập, và ghi URL mới nếu không. (hitechcloudcli#454)
• Greylisting được bật trước khi bộ nhớ đệm được bảo vệ đã ngừng hoạt động mà không báo gì; nay thông tin đăng nhập bộ nhớ đệm của rspamd được ghi và kiểm tra theo cách rspamd đăng nhập, và greylist show phân biệt đăng nhập bị từ chối với bộ nhớ đệm không kết nối được. webmail doctor đăng nhập vào bộ nhớ đệm thay vì chỉ mở kết nối, và việc kết thúc phiên của người dùng (đổi mật khẩu, xóa, tạm ngưng) đọc thông tin đăng nhập bộ nhớ đệm của panel theo cách engine đọc. (hitechcloudcli#460)
• mail tls, lệnh chạy sau mỗi lần cấp và gia hạn chứng chỉ, báo Postfix và Dovecot đang dùng chứng chỉ mới ngay cả khi một trong hai không chạy lại; nay nó kiểm tra cấu hình Dovecot trước khi nạp lại, nêu tên dịch vụ không chạy sau đó, và thoát với mã 1. (hitechcloudcli#455)
• Bản cập nhật không còn giải nén bản phát hành mới đè lên bản đang chạy: nó giải nén bên cạnh rồi hoán đổi vào khi mọi thứ đã sẵn sàng, nên ổ đầy hoặc việc giải nén bị gián đoạn để nguyên các tệp đang dùng. Mọi tệp nhị phân nó cài đều được ghi xuống đĩa trước khi đổi tên vào chỗ. (hitechcloudcli#463, #464)
• Các bản sao lưu tạo trước khi đổi tên của một tài khoản đã đổi tên bị xóa sau thời hạn xóa GDPR như thể tài khoản đã bị chấm dứt. Nay việc xóa theo dõi việc đổi tên. (hitechcloudcli#456)
• Sentinel bỏ sót các lần tiến trình bị kết thúc do hết bộ nhớ: nó chỉ đọc một tệp syslog, chỉ các lần kết thúc theo nhóm và chỉ một định dạng ngày. Nay nó đọc nhật ký kernel và báo mỗi lần một lần, kể cả lần kết thúc trên toàn máy chủ. (hitechcloudcli#452)
• 2083: các trang đăng nhập, quên mật khẩu và thành viên nhóm liệt kê mỗi ngôn ngữ bằng tên riêng của nó (日本語, Tiếng Việt, العربية) thay vì mã. (HiTechCloud-Panel#1759)
• 2083: mẫu nhập liệu của các biểu mẫu tên miền mới, thư mục gốc, danh sách thư, FTP ẩn danh và triển khai git không biên dịch được trong trình duyệt nên bị bỏ qua; nay chúng có hiệu lực. (HiTechCloud-Panel#1762)
• 2083: thông báo bí danh tên miền được dịch, các liên kết sắp xếp của trang hoạt động có tên, và các phát hiện về khả năng tiếp cận trên những trang thêm trong 4.1.2 được sửa. (HiTechCloud-Panel#1756, #1757)
• 2087: cờ của mọi ngôn ngữ hiển thị trên Settings > Locales; sửa menu, mẫu biểu mẫu và độ tương phản trên những trang thêm trong 4.1.2; trang Services kiểm tra đúng socket bộ nhớ đệm mà engine của panel dùng. (hitechcloudadmin#317, #320, #321)
• Bản dịch: tiếng Ba Lan đầy đủ và không còn mục mồ côi, và các thông báo yếu tố thứ hai của Sao chép cơ sở dữ liệu có trong cả tám ngôn ngữ dịch máy. Các danh mục dịch máy của 2087 nay được CI đối chiếu với danh mục tiếng Việt. (translations#67, hitechcloudadmin#319)

Bảo mật​

• Trên máy chủ có bộ nhớ đệm được bảo vệ, việc đăng xuất các phiên webmail khác của một hộp thư sau khi đặt lại hoặc đổi mật khẩu, và đăng xuất back-channel OpenID Connect, hoạt động trở lại (một hạn chế đã biết của 4.1.3). Webmail nay tìm các phiên của người dùng qua một chỉ mục nó lưu bên cạnh thay vì SCAN, lệnh mà thông tin đăng nhập bộ nhớ đệm của nó bị từ chối. (hitechcloudmail#90, hitechcloudcli#469)
• Mọi khóa của webmail nằm dưới Webmail:. Không tên tài khoản nào bắt đầu bằng chữ hoa, nên không thông tin đăng nhập bộ nhớ đệm của tài khoản hosting nào chạm tới được phiên, giới hạn tần suất hay bộ chống phát lại của webmail, và người dùng bộ nhớ đệm riêng của webmail bị giới hạn trong Webmail:*. Trong 4.1.3, một tài khoản tên chẳng hạn sess có thể đã ghi đè phiên webmail; 4.1.3 từ chối các tên như vậy như một biện pháp tạm thời. (hitechcloudmail#90, hitechcloudcli#469)
• Việc xóa bộ nhớ đệm khi panel khởi động đã xóa cả trạng thái phải tồn tại qua lần khởi động lại: thu hồi token ("đăng xuất khỏi mọi nơi", đổi mật khẩu), bộ đếm khóa đăng nhập, dấu chống phát lại TOTP, token đặt lại mật khẩu, và các refresh token đã dùng cùng các họ token đã thu hồi của API cổng. Mỗi lần panel khởi động lại đều mở lại tất cả. Nay chúng được giữ lại. (HiTechCloud-Panel#1775)
• Panel, 2087 và CLI chỉ gửi thông tin đăng nhập bộ nhớ đệm của panel qua unix socket khi socket đó thuộc root hoặc một người dùng hệ thống. Socket mặc định nằm trong thư mục ai cũng ghi được, nơi một tài khoản hosting có thể lắng nghe thay chỗ và nhận được mật khẩu quản trị của bộ nhớ đệm. Hai họ khóa cuối cùng của panel nằm ngoài tiền tố của nó (tokens_valid_after, email_import) đã chuyển vào dưới tiền tố, nên tài khoản đặt tên trùng chúng không còn khôi phục được các token đã thu hồi. (HiTechCloud-Panel#1758, hitechcloudadmin#318, #320)
• Thông tin đăng nhập bộ nhớ đệm của tài khoản hosting không bao giờ được tạo thiếu các lệnh cấm: SCAN, KEYS, RANDOMKEY, DBSIZE, PUBSUB và SCRIPT luôn bị từ chối, và engine từ chối mọi bộ quy tắc an toàn sẽ để tài khoản không có thông tin đăng nhập bộ nhớ đệm và nói rõ điều đó, thay vì lùi về một thông tin đăng nhập có thể liệt kê mọi khóa trên phiên bản. Trên Redis 6.0, vốn không có quyền theo kênh, thông tin đăng nhập của tài khoản và của greylisting hoàn toàn không có publish/subscribe. (hitechcloudcli#461, #467)
• Khôi phục cơ sở dữ liệu không bao giờ chạy với quyền root và không bao giờ dùng thông tin đăng nhập của tài khoản khác. (hitechcloudcli#457)
• Quy tắc sudo root của webmail, không còn dùng từ 4.0.8, bị gỡ khi cập nhật. (hitechcloudcli#458)
• Phiên của một tài khoản có thể sao chép cơ sở dữ liệu sang tài khoản khác của cùng khách hàng và nhờ đó chạy SQL với quyền tài khoản kia mà không cần yếu tố thứ hai hay danh sách cho phép của nó; nay việc sao chép hỏi những gì việc chuyển tài khoản hỏi. (HiTechCloud-Panel#1752)

Hạn chế đã biết​

• Hộp thư được tạo trong 2083 khi đăng nhập hoặc tạo hộp thư đang lỗi trên 4.1.2 có thể chưa bao giờ được tạo đầy đủ: mật khẩu của nó bị từ chối qua IMAP và mở webmail từ 2083 sẽ quay về danh sách hộp thư. Bản cập nhật không sửa hộp thư như vậy. Hãy đặt lại mật khẩu của nó trong 2083, hoặc xóa rồi tạo lại.
• Greylisting vẫn tắt trên Ubuntu 22.04 và Debian 12 khi bộ nhớ đệm được bảo vệ, vì rspamd của chúng không đăng nhập được bằng tên người dùng (xem Ghi chú nâng cấp).