PAM_SYSTEMD_HOME(8) pam_systemd_home PAM_SYSTEMD_HOME(8)

pam_systemd_home - مدیریت احراز هویت و فعالسازی دایرکتوری خانگی کاربر

pam_systemd_home.so

ماژول pam_systemd_home اطمینان حاصل می‌کند که دایرکتوری‌های خانگی مدیریت‌شده توسط systemd-homed.service(8) هنگام ورود کاربر به‌طور خودکار فعال (سوار یا mount) شده، و با پایان یافتن آخرین نشست کاربر غیرفعال (پیاده یا unmount) شوند. همچنین برای چنین کاربرانی، این ماژول احراز هویت (در صورت استفاده از رمزنگاری دیسک به‌ازای هر کاربر، کلید رمزنگاری دیسک از اطلاعات هویتی ارائه‌شده هنگام ورود استخراج می‌شود)، مدیریت حساب ( رِکورد کاربری JSON[1] تعبیه‌شده در مخزن داده‌های خانگی، شامل جزئیات حساب است) و پیاده‌سازی به‌روزرسانی گذرواژه رمزنگاری (که برای احراز هویت کاربر نیز استفاده می‌شود) را فراهم می‌کند.

گزینه‌های زیر پشتیبانی می‌شوند:

suspend=

یک آرگومان بولی (boolean) می‌پذیرد. در صورت تنظیم روی true، دایرکتوری خانگی کاربر در طول تعلیق (suspend) سیستم به‌طور خودکار معلق می‌شود؛ در صورت تنظیم روی false فعال باقی خواهد ماند. تعلیق خودکار دایرکتوری خانگی امنیت را به‌میزان قابل‌توجهی افزایش می‌دهد، زیرا داده‌های کلید محرمانه قبل از به خواب رفتن سیستم به‌طور خودکار از حافظه رم پاک می‌شوند و هنگام بازگشت از تعلیق باید دوباره (از طریق احراز هویت مجدد کاربر) به‌دست آیند. توصیه می‌شود این پارامتر برای تمام برنامه‌های PAM که از احراز هویت مجدد خودکار از طریق PAM هنگام ازسرگیری سیستم (resume) پشتیبانی می‌کنند، تنظیم شود. اگر چندین نشست از یک کاربر به‌طور همزمان باز باشد، مادامی که حداقل یکی از نشست‌ها این پارامتر را فعال (on) نکرده باشد، دایرکتوری خانگی کاربر هنگام تعلیق سیستم بدون تعلیق باقی می‌ماند. مقدار پیش‌فرض off است.

توجه داشته باشید که ورودهای TTY عموماً از احراز هویت مجدد هنگام ازسرگیری سیستم پشتیبانی نمی‌کنند. احراز هویت مجدد هنگام بازگشت از تعلیق، اساساً مفهومی قابل‌پیاده‌سازی در محیط‌های گرافیکی است که در قالب قفل صفحه‌هایی که با به خواب رفتن سیستم به‌طور خودکار فعال می‌شوند ارائه می‌گردد. این بدان معناست که اگر کاربری به‌طور همزمان از نشست‌های ورود گرافیکی (که سازوکار احراز هویت مجدد موردنیاز را پیاده‌سازی کرده‌اند) و ورودهای کنسولی (که این کار را نمی‌کنند) استفاده کند، با توجه به منطق توضیح داده‌شده در بالا، دایرکتوری خانگی در هنگام تعلیق قفل نمی‌شود. با این حال، می‌توان این فیلد را برای ورودهای TTY نیز تنظیم کرد و این واقعیت را که نشست‌های TTY عملاً از سازوکار احراز هویت مجدد پشتیبانی نمی‌کنند نادیده گرفت. در این حالت، نشست‌های TTY تا زمانی که کاربر در یک ترمینال مجازی دیگر (چه از طریق یک نشست TTY دیگر و چه به‌صورت گرافیکی) وارد شود، معلق (hang) به نظر می‌رسند که ورود جدید باعث ازسرگیری دایرکتوری خانگی و رفع انسداد نشست TTY اصلی خواهد شد. (توجه داشته باشید که عدم وجود قفل صفحه در نشست‌های TTY به این معنی است که هرچند نشست TTY معلق به نظر می‌رسد، اما کلیدهای فشرده‌شده همچنان می‌توانند در صف آن قرار گیرند و محتویات صفحه موجود را می‌توان بدون احراز هویت مجدد خواند؛ این محدودیت ارتباطی با مدیریت دایرکتوری خانگی که توسط pam_systemd_home و systemd-homed.service پیاده‌سازی شده ندارد.)

فعال کردن این گزینه به‌صورت پیش‌فرض برای تمام نشست‌ها به‌شدت توصیه می‌شود، اما تنها در صورتی که سرویس ارائه‌دهنده این نشست‌ها احراز هویت مجدد مذکور را به‌درستی پیاده‌سازی کرده باشد. توجه داشته باشید که احراز هویت مجدد باید از سوی مؤلفه‌ای انجام شود که خارج از بستر (context) کاربر اجرا می‌شود، تا برای عملکرد خود نیازی به دسترسی به دایرکتوری خانگی کاربر نداشته باشد. به‌طور سنتی، بیشتر محیط‌های رومیزی قفل صفحه را به این روش پیاده‌سازی نمی‌کنند و باید متناسب با آن به‌روزرسانی شوند.

این تنظیمات همچنین می‌تواند از طریق متغیر محیطی $SYSTEMD_HOME_SUSPEND (در ادامه ببینید) کنترل شود، که pam_systemd_home در هنگام راه‌اندازی اولیه آن را می‌خواند و برای نشست‌ها تنظیم می‌کند. اگر هم متغیر محیطی تنظیم شده باشد و هم پارامتر ماژول مشخص شده باشد، پارامتر ماژول اولویت دارد.

اضافه‌شده در نسخه 245.

debug[=]

یک آرگومان بولی اختیاری می‌پذیرد. در صورت مقدار yes یا بدون آرگومان، ماژول در حین کار اطلاعات اشکال‌زدایی را ثبت می‌کند.

اضافه‌شده در نسخه 245.

دایرکتوری‌های خانگی مدیریت‌شده توسط systemd-homed.service(8) از چندین «ناحیه» (areas) خانگی پشتیبانی می‌کنند، که دایرکتوری‌های خانگی ثانویه اضافی برای کاربر در درون دایرکتوری خانگی اصلی هستند. به عنوان مثال: در هنگام ورود، اگر کاربری به نام "lennart" با دایرکتوری خانگی /home/lennart نام حساب کاربری را هنگام ورود به‌صورت "lennart%versuch1" مشخص کند، آن‌گاه pam_systemd_home فرآیند ورود را برای کاربر "lennart" اجرا می‌کند اما اطمینان حاصل می‌نماید که متغیر $HOME به‌جای مقدار معمول /home/lennart روی /home/lennart/Areas/versuch1 تنظیم شود.

این قابلیت به‌ویژه هنگام به اشتراک گذاشتن یک دایرکتوری خانگی میان چند سیستم (به عنوان مثال میان میزبان و یک ماشین مجازی) بسیار مفید است، در شرایطی که تمایل وجود دارد بخش عمده دایرکتوری خانگی به اشتراک گذاشته شود، اما همچنان پیکربندی نشست‌های مجزا برقرار باشد.

توجه داشته باشید که ناحیه پیش‌فرض برای ورود می‌تواند در رِکورد کاربر نیز کدگذاری شود، و می‌توان آن را در میان پارامترهای پیکربندی pam_systemd(8) نیز مشخص کرد. با این حال، یک ناحیه صریح که در زمان ورود (از طریق ساختار "%" توضیح داده شده در بالا) مشخص شده باشد، بر تمام مقادیر پیش‌فرض اولویت خواهد داشت. همچنین توجه داشته باشید که افزودن پسوند ساده "%" به انتهای نام حساب در زمان ورود (یعنی مشخص کردن یک نام ناحیه خالی)، ورود مستقیم به دایرکتوری خانگی اصلی را تضمین می‌کند و بر هرگونه پیکربندی ناحیه پیش‌فرض از طریق رِکورد کاربر یا PAM اولویت دارد.

توجه داشته باشید که همه سازوکارهای ورود با ساختار "%" در زمان ورود سازگار نیستند. به‌ویژه برنامه ssh(8) با آن سازگار نیست.

توجه داشته باشید که دایرکتوری ناحیه مورد نظر برای ورود باید وجود داشته باشد تا مشخصات ناحیه اعمال شود. اگر ناحیه‌ای در هنگام ورود از طریق منطق "%" (یا سایر سازوکارهای ذکر شده) مشخص شود ولی در عمل وجود نداشته باشد، این درخواست نادیده گرفته می‌شود و کاربر در عوض وارد دایرکتوری خانگی اصلی خواهد شد.

به‌طور معمول، برای استفاده از این سازوکار ابتدا یک ناحیه را به این شکل ایجاد کنید:

lennart@zeta$ mkdir -p ~/Areas
lennart@zeta$ cp -av /etc/skel ~/Areas/versuch1

این برای ورود به ناحیه تازه‌تأسیس کافی است، چه از طریق یک ترمینال معمولی (با وارد کردن "lennart%versuch1" هنگام درخواست نام کاربری)، یا از طریق run0(1):

lennart@zeta$ run0 --area=versuch1

این ماژول هر چهار عملیات PAM را پیاده‌سازی می‌کند: auth (برای فراهم کردن امکان احراز هویت با استفاده از داده‌های رمزنگاری‌شده)، account (زیرا کاربرانی که حساب‌های کاربری systemd-homed.service دارند در یک رِکورد کاربری JSON[1] شرح داده شده‌اند و می‌توان آن‌ها را با جزئیات بیشتری نسبت به پایگاه‌داده سنتی کاربران لینوکس پیکربندی کرد)، session (زیرا نشست‌های کاربر باید ردیابی شوند تا آزادسازی خودکار هنگام خروج آخرین نشست کاربر انجام شود)، password (برای تغییر گذرواژه رمزنگاری — که برای احراز هویت کاربر نیز استفاده می‌شود — از طریق PAM).

متغیرهای محیطی زیر توسط ماژول مقداردهی اولیه شده و برای فرایندهای نشست کاربر در دسترس هستند:

$SYSTEMD_HOME=1

نشان می‌دهد که دایرکتوری خانگی کاربر توسط systemd-homed.service مدیریت می‌شود.

اضافه‌شده در نسخه 245.

$SYSTEMD_HOME_SUSPEND=

نشان می‌دهد که آیا نشست با سازوکار تعلیق فعال یا غیرفعال ثبت شده است (به بخش بالا مراجعه کنید). مقدار این متغیر یا "0" یا "1" است. توجه داشته باشید که این ماژول هنگام راه‌اندازی اولیه هم این متغیر را می‌خواند و هم آن را برای نشست‌ها تنظیم می‌کند.

اضافه‌شده در نسخه 246.

در اینجا نمونه‌ای از یک قطعه پیکربندی PAM آورده شده است که به کاربران مدیریت‌شده توسط systemd-homed.service اجازه ورود می‌دهد:

#%PAM-1.0
    -auth     [success=done authtok_err=bad perm_denied=bad maxtries=bad default=ignore] pam_systemd_home.so
auth      sufficient pam_unix.so
auth      required   pam_deny.so
account   required   pam_nologin.so
-account  [success=done authtok_expired=bad new_authtok_reqd=bad maxtries=bad acct_expired=bad default=ignore] pam_systemd_home.so
account   required   pam_unix.so
-password sufficient pam_systemd_home.so
password  sufficient pam_unix.so sha512 shadow try_first_pass
password  required   pam_deny.so
-session  optional   pam_keyinit.so revoke
-session  optional   pam_loginuid.so
-session  optional   pam_systemd_home.so
-session  optional   pam_systemd.so
session   required   pam_unix.so

systemd(1), systemd-homed.service(8), homed.conf(5), homectl(1), pam_systemd(8), pam.conf(5), pam.d(5), pam(8)

1.
رِکورد کاربری JSON
https://systemd.io/USER_RECORD
systemd 261.2