READERS.CONF(5) InterNetNews Documentation READERS.CONF(5)

readers.conf - کنترل دسترسی و پیکربندی nnrpd

فایل readers.conf پارامترهای مربوط به این که چه کسی مجاز به اتصال به عنوان یک خواننده گروه‌های خبری است و پس از اتصال مجاز به انجام چه کارهایی است را تعیین می‌کند. به خاطر داشته باشید که در readers.conf، احراز هویت (authentication) و مجوزدهی (authorization) در بلوک‌های متفاوتی پیکربندی می‌شوند. ابتدا، هویت کاربر احراز شده و یک شناسه هویتی به او اختصاص می‌یابد (در یک بلوک "auth"). سپس به این هویت مجوز دسترسی به گروه‌های خبری مشخصی با حقوق معین اعطا می‌شود (در یک بلوک "access").

در رابطه با احراز هویت، بلوک "auth" شما برای کاربرانی که با گذرواژه متصل می‌شوند می‌تواند به شکل زیر باشد:

auth "foreignokay" {
    auth: "ckpasswd -f <pathdb in inn.conf>/newsusers"
    default: "<unauthenticated>"
}

برای آگاهی از نحوه تولید گذرواژه‌ها و استفاده از این فایل newsusers، به مستندات گزینه -f در صفحه راهنمای ckpasswd(8) مراجعه فرمایید.

به این ترتیب، با استفاده از بلوک احراز هویت "foreignokay"، کاربری که با موفقیت با نام "myusername" احراز هویت شود، شناسه هویتی "myusername" را دریافت خواهد کرد. اگر احراز هویت با شکست مواجه شود، هویت پیش‌فرض "<unauthenticated>" به او اختصاص می‌یابد که بعداً در بلوک‌های "access" ارزیابی خواهد شد.

بلوک‌های احراز هویت از آخرین بلوک موجود در فایل readers.conf تا اولین بلوک (از پایین به بالا) بررسی می‌شوند. به محض اینکه یک بلوک با شرایط اتصال مطابقت پیدا کند، هویت متناظر به کاربر اختصاص داده می‌شود.

در خصوص اعطای دسترسی و مجوزها، می‌توانیم در یک بلوک "access" برای کاربرانی که با موفقیت با گذرواژه احراز هویت شده‌اند، چنین تعریفی داشته باشیم:

access "authenticatedpeople" {
    users: "*"
    newsgroups: "*,!junk,!control,!control.*"
}

و سپس بسته به اینکه آیا کاربران احراز هویت‌نشده اصلاً دسترسی دریافت می‌کنند یا خیر، چیزی شبیه به یکی از دو مورد زیر تعریف می‌شود:

access "restrictive" {
    users: "<unauthenticated>"
    newsgroups: "!*"
}
access "readonly" {
    users: "<unauthenticated>"
    read: "local.*"
    post: "!*"
}

لطفاً توجه داشته باشید که بلوک "authenticatedpeople" باید پیش از بلوک‌های "restrictive" یا "readonly" در فایل readers.conf قرار گیرد، زیرا بلوک‌های دسترسی از آخرین بلوک موجود در فایل readers.conf تا اولین بلوک (از پایین به بالا) بررسی می‌شوند. به محض اینکه یک بلوک با هویت اختصاص‌یافته توسط یک بلوک احراز هویت مطابقت کند، انتخاب خواهد شد. بلوک دسترسی "authenticatedpeople" با تمام کاربرانی که هویت "<unauthenticated>" به آن‌ها داده نشده است تطابق دارد.

مثال‌ها و قابلیت‌های بیشتر در ادامه این صفحه راهنما به تفصیل شرح داده شده است (به‌ویژه بدون فایل گذرواژه، با PAM، یا با قلاب‌های Perl یا Python).

پس از ایجاد تغییرات در readers.conf نیازی به بارگذاری مجدد هیچ سرویسی ندارید؛ هر بار که یک کلاینت خبرخوان به سرور متصل می‌شود، یک فرآیند جدید nnrpd ایجاد شده و پیکربندی خود را از دیسک می‌خواند. با این حال، پس از هر تغییر می‌توانید دستور "inncheck" را اجرا کنید تا اعتبارسنجی نحوی پایه‌ای روی فایل readers.conf انجام شود.

فایل readers.conf در دایرکتوری pathetc، کنترل دسترسی را برای nnrpd(8) مشخص می‌کند. این فایل کنترل می‌کند چه کسانی مجاز به اتصال به عنوان خواننده اخبار هستند و پس از اتصال چه کارهایی می‌توانند انجام دهند. nnrpd هر بار که یک کلاینت اخبار به سرور وصل می‌شود این فایل را بازخوانی می‌کند، حتی زمانی که در حالت دیمن با گزینه -D در حال اجراست؛ این بدان معناست که هرگونه تغییر در این فایل بلافاصله بر تمامی اتصالات بعدی اعمال می‌شود. (مکان readers.conf در pathetc صرفاً مسیر پیش‌فرض است؛ همین قالب برای هر فایلی که با "nnrpd -c" مشخص شود نیز صدق می‌کند.)

دو نوع مدخل در readers.conf وجود دارد: جفت‌های پارامتر/مقدار و گروه‌های پیکربندی. خطوط خالی و هر چیزی پس از علامت هش ("#") نادیده گرفته می‌شوند، مگر آنکه نویسه "#" با "\" اسکیپ شده باشد. حداکثر تعداد نویسه‌ها در هر خط ۸٬۱۹۱ نویسه است.

جفت‌های پارامتر/مقدار شامل یک کلمه کلیدی هستند که بلافاصله پس از آن یک دونقطه، حداقل یک نویسه فاصله و یک مقدار قرار می‌گیرد. بزرگی و کوچکی حروف در نام پارامتر حائز اهمیت است (پارامترها عموماً باید با حروف کوچک نوشته شوند)، و یک پارامتر می‌تواند شامل هر نویسه‌ای به جز دونقطه، "#" و فاصله باشد. به عنوان مثال:

hosts: *.example.com

مقادیری که شامل فاصله هستند باید در گیومه دوتایی قرار گیرند، مانند:

hosts: "*.example.com, *.example.net"

اگر پارامتر حاوی فاصله نباشد، مانند:

hosts: *.example.com,*.example.net

نیازی به قرار دادن آن در گیومه نیست، اگرچه ممکن است برای شفافیت بیشتر مایل به انجام این کار باشید.

هیچ راهی برای ادامه دادن یک خط در خط بعدی وجود ندارد، و بنابراین نمی‌توان یک پارامتر تکی با مقداری بیش از حدود ۸٬۱۸۰ نویسه داشت.

بسیاری از پارامترها مقادیر بولی (boolean) می‌پذیرند. برای تمامی این پارامترها، مقدار می‌تواند به صورت "true"، "yes" یا "on" برای فعال‌سازی، و هر یک از مقادیر "false"، "no" یا "off" برای غیرفعال‌سازی مشخص شود. بزرگی و کوچکی حروف در این مقادیر بی‌تاثیر است.

دو نوع اصلی از گروه‌های پیکربندی وجود دارد: auth و access. گروه auth سازوکارهایی برای تعیین هویت کاربر (اینکه چه کسی است) فراهم می‌کند. گروه access با توجه به هویت کاربر، تعیین می‌کند که کاربر مجاز به انجام چه اقداماتی است. نگارش یک فایل readers.conf برای سیستم شما یک فرآیند دو مرحله‌ای است: ابتدا اختصاص یک هویت به هر اتصال ورودی با استفاده از گروه‌های auth، و سپس اعطای دسترسی‌ها و امتیازات مناسب به هر هویت با استفاده از گروه‌های access. توصیه می‌کنیم گروه‌های auth و گروه‌های access را در فایل پیکربندی با یکدیگر درنیامیزید؛ اغلب منطقی‌تر است (در صورت عدم استفاده از پارامتر key) که ابتدا تمامی گروه‌های auth و سپس تمام گروه‌های access در پایین قرار داده شوند.

هویت کاربر که توسط یک گروه auth تثبیت می‌شود، در صورت مشخص بودن دامنه به شکل یک آدرس ایمیل (مانند "<username>@<domain>") و در غیر این صورت صرفاً به شکل "<username>" خواهد بود.

اگر گزینه nnrpdauthsender در inn.conf فعال باشد، هویت کاربر در فیلد سرآیند Sender مقالات ارسال‌شده توسط آن کاربر نیز درج می‌شود. برای جزئیات بیشتر به مستندات این گزینه در inn.conf(5) مراجعه کنید.

تعریف یک گروه auth به این صورت است:

auth <name> {
    hosts: <host-wildmat>
    auth: <auth-program>
    res: <res-program>
    default: <defuser>
    default-domain: <defdomain>
    # ...possibly other settings
}

شناسه <name> به عنوان برچسبی برای گروه استفاده می‌شود و صرفاً برای مقاصد مستندسازی است. (اگر پیکربندی syslog شما تسهیلات "news.debug" را ثبت کند، مقدار <name> در خروجی اشکال‌زدایی nnrpd ظاهر می‌شود. بررسی این خروجی می‌تواند در فهمیدن اینکه چرا پیکربندی شما آن‌طور که انتظار دارید عمل نمی‌کند بسیار مفید باشد.)

یک گروه auth مشخص تنها برای میزبان‌هایی اعمال می‌شود که نام یا آدرس IP آن‌ها با عبارت وایلد‌مت (wildmat) تعیین‌شده با پارامتر hosts تطابق داشته باشد (عبارت‌های وایلد‌مت جداشده با کاما مجاز هستند، اما "@" پشتیبانی نمی‌شود). به جای عبارت‌های وایلد‌مت، می‌توانید از نمادگذاری CIDR نیز برای تطبیق هر آدرس IP درون یک بلوک شبکه استفاده کنید؛ برای مثال، "10.10.10.0/24" با هر آدرس IP بین 10.10.10.0 و 10.10.10.255 شامل هر دو مطابقت خواهد داشت.

در صورت کامپایل شدن برنامه با کتابخانه‌های TLS/SSL یا SASL، یک گروه auth با پارامتر require_encryption تنظیم‌شده بر روی true، تنها زمانی اعمال می‌شود که اتصال ورودی از یک لایه رمزنگاری استفاده کند؛ خواه از همان ابتدا با ارسال پرچم -S به nnrpd، خواه پس از مذاکره موفق STARTTLS، یا پس از احراز هویت موفق با استفاده از مکانیزم SASL که لایه رمزنگاری را مذاکره می‌کند.

برای هر اتصال از میزبانی که با آن عبارت وایلد‌مت یا بلوک شبکه مطابقت داشته باشد، هر <res-program> (ممکن است چندین خط res در یک بلوک وجود داشته باشد؛ آن‌ها به ترتیب تا موفقیت یکی اجرا می‌شوند)، در صورت وجود، اجرا می‌شود تا هویت کاربر را صرفاً از اطلاعات اتصال تشخیص دهد. اگر تمام برنامه‌های تحلیل‌گر (resolvers) شکست بخورند، یا اگر پارامتر res وجود نداشته باشد، به کاربر هویت "<defuser>@<defdomain>" اختصاص می‌یابد؛ به عبارت دیگر، مقادیر پارامترهای default و default-domain به کار گرفته می‌شوند. اگر <res-program> تنها یک نام کاربری برگرداند، از مقدار <defdomain> به عنوان دامنه استفاده خواهد شد.

اگر کاربر بعداً از طریق دستورات AUTHINFO USER/PASS اقدام به احراز هویت کند، نام کاربری و گذرواژه ارائه‌شده به هر <auth-program> ارسال می‌گردد (ممکن است چندین خط auth، perl_auth یا python_auth در یک بلوک حضور داشته باشند؛ آن‌ها به ترتیب تا زمان موفقیت یکی اجرا می‌شوند). اگر یکی از آن‌ها موفق شود و هویتی متفاوت از هویت تعیین‌شده در زمان اتصال اولیه بازگرداند، مجدداً با گروه‌های دسترسی موجود تطبیق داده می‌شود و کارهایی که کاربر مجاز به انجام آن‌ها است ممکن است تغییر یابد. رایج‌ترین <auth-program> برنامه ckpasswd است که از چندین روش برای بررسی گذرواژه‌ها از جمله استفاده از PAM پشتیبانی می‌کند. برای جزئیات بیشتر صفحه راهنمای ckpasswd(8) را مطالعه کنید.

هنگام تطبیق گروه‌های auth، آخرین گروه auth موجود در فایل که با یک اتصال مشخص و ترکیب نام کاربری/گذرواژه تطابق داشته باشد اعمال می‌شود.

تعریف یک گروه access معمولاً به شکل زیر است:

access <name> {
    users: <identity-wildmat>
    newsgroups: <group-wildmat>
    # ...possibly other settings
}

باز هم، <name> صرفاً برای مقاصد مستندسازی است. این ساختار بیان می‌کند تمام کاربرانی که هویت آن‌ها با <identity-wildmat> تطابق دارد می‌توانند در تمامی گروه‌های خبری منطبق با <group-wildmat> بخوانند و پیام ارسال کنند (همانند قبل، عبارت‌های وایلد‌مت جداشده با کاما مجاز هستند، اما "@" پشتیبانی نمی‌شود). به صورت متناوب، می‌توانید از فرم زیر استفاده کنید:

access <name> {
    users: <identity-wildmat>
    read: <read-wildmat>
    post: <post-wildmat>
}

و کاربران منطبق قادر خواهند بود هر گروهی را که با <read-wildmat> مطابقت دارد بخوانند و در هر گروهی که با <post-wildmat> تطابق دارد ارسال خبر کنند. شما همچنین می‌توانید موارد متعدد دیگری را در گروه access تنظیم کرده و همچنین پارامترهای مختلف inn.conf(5) را صرفاً برای یک گروه خاص از کاربران بازنویسی (override) نمایید.

درست همانند گروه‌های auth، هنگام تطبیق گروه‌های access نیز آخرین گروه منطبق در فایل برای تعیین دسترسی‌های کاربر انتخاب می‌شود. یک استثنا برای این قاعده وجود دارد: اگر گروه auth منطبق با کلاینت شامل پارامتر perl_access یا python_access باشد، اسکریپتی که به عنوان آرگومان داده شده برای تولید پویا یک گروه access به کار می‌رود. این گروه دسترسی جدید سپس برای تعیین حقوق دسترسی کلاینت استفاده شده و گروه‌های access موجود در فایل نادیده گرفته می‌شوند.

یک حالت خاص دیگر نیز وجود دارد که باید در نظر داشت. هنگام ایجاد قوانین پیچیده احراز هویت و اعطای مجوز، گاهی اوقات مفید است که هویت‌های ارائه‌شده توسط یک گروه auth معین صرفاً بر گروه‌های access خاصی اعمال گردند؛ به عبارت دیگر، به جای بررسی هویت در برابر پارامتر users تمامی گروه‌های access، بررسی فقط در برابر پارامتر users چند گروه دسترسی خاص انجام پذیرد. این کار به کمک پارامتر key انجام می‌شود. برای مثال:

auth example {
    key: special
    hosts: *.example.com
    default: <SPECIAL>
}
access example {
    key: special
    users: <SPECIAL>
    newsgroups: *
    addcanlockuser: none
}

در این مثال، دو پارامتر key این گروه auth را به این گروه access پیوند می‌دهند. برای هر اتصال ورودی منطبق با "*.example.com" (با این فرض که گروه auth دیگری در ادامه نیامده باشد که با این میزبان‌ها تطابق پیدا کند)، هیچ گروه دسترسی که فاقد "key: special" باشد حتی بررسی نخواهد شد. به همین ترتیب، گروه access فوق فقط در صورتی ارزیابی می‌شود که کاربر با یک گروه auth حاوی "key: special" احراز هویت شده باشد. این مکانیزم معمولاً چندان مورد نیاز نیست؛ چرا که تقریباً همیشه روش بهتری برای دستیابی به همین نتیجه وجود دارد.

همچنین در این مثال توجه داشته باشید که پارامتر default-domain تعریف نشده است، به این معنی که هیچ دامنه‌ای به نام کاربری پیش‌فرض الحاق نمی‌شود و هویت این اتصالات صرفاً "<SPECIAL>" خواهد بود. توجه داشته باشید که برخی از ابزارهای الحاقی INN ترجیح می‌دهند هویت‌های احراز هویت‌شده همیشه یک آدرس ایمیل کامل (شامل دامنه) باشند، بنابراین اگر از این ابزارهای الحاقی استفاده می‌کنید، ممکن است بخواهید سیستم خود را به این شیوه پیکربندی کنید. از آنجا که چندین فرد مختلف می‌توانند هویت یکسان "<SPECIAL>" را دریافت کنند، هیچ هش اختصاصی کاربر برای Cancel-Lock نباید تولید گردد.

فایل‌های پیکربندی را می‌توان با استفاده از نحو زیر در فایل‌های پیکربندی دیگر گنجاند:

include <filename>

بدین ترتیب، فایلی با نام <filename> فراخوانی و گنجانده می‌شود. این نحو فقط در سطح بالای فایل (top-level) مجاز است.

در ادامه فهرست کامل پارامترهای مجاز برای گروه‌های auth و گروه‌های access ارائه شده است، و پس از آن چند مثال کاربردی برای شفاف‌تر شدن این مفاهیم آورده شده است.

یک گروه auth بدون وجود حداقل یکی از پارامترهای res، auth، perl_auth، python_auth یا default کاملاً بی‌معنی است (و در عمل نادیده گرفته می‌شود).

یک خط فرمان ساده برای احراز هویت‌کننده کاربر (کاراکترهای متا در شل پشتیبانی نمی‌شوند). اگر یک مسیر کامل داده نشود، برنامه اجراشده باید در دایرکتوری pathbin/auth/passwd قرار داشته باشد. احراز هویت‌کننده برنامه‌ای است که برای رسیدگی به نام کاربری و گذرواژه ارائه‌شده توسط کاربر، از طریق سازوکاری مانند AUTHINFO USER/PASS استفاده می‌شود. همانند res، یک گروه auth می‌تواند چندین پارامتر auth داشته باشد؛ آن‌ها به ترتیب آزموده می‌شوند و خروجی نخستین موردی که موفق شود به کار می‌رود. همچنین perl_auth را ببینید.

رایج‌ترین احراز هویت‌کننده مورد استفاده ckpasswd(8) است؛ برای اطلاعات بیشتر به صفحه راهنمای آن رجوع کنید.

نام کاربری پیش‌فرض برای اتصالات منطبق با این گروه auth. این نام کاربری در زمان اتصال، در صورت شکست تمامی برنامه‌های تحلیل‌گر یا در غیاب پارامترهای res، به کاربر نسبت داده می‌شود. توجه داشته باشید که این مقدار می‌تواند یک نام کاربری ساده باشد، که در این صورت default-domain (در صورت وجود) پس از یک "@" به انتهای آن افزوده می‌شود، یا یک رشته هویتی کامل شامل "@" باشد که در این حالت عیناً استفاده خواهد شد.
رشته دامنه پیش‌فرض برای این گروه auth. اگر تحلیل‌گر کاربر یا برنامه احراز هویت دامنه‌ای ارائه ندهد، یا اگر از نام کاربری پیش‌فرض استفاده شود و فاقد "@" باشد، از این دامنه برای تشکیل هویت کاربر استفاده می‌شود. (توجه داشته باشید که در بسیاری از سیستم‌ها، اصولاً نیازی نیست هویت کاربران همراه با نام دامنه مشخص شود، که در این حالت نیازی به استفاده از این پارامتر نیست.)
فهرستی جداشده با کاما از میزبان‌های دوردست، الگوهای وایلد‌مت منطبق با نام‌های میزبان یا آدرس‌های IP، یا بلوک‌های شبکه IP در قالب نمادگذاری CIDR. اگر کاربری از میزبانی متصل شود که با این پارامتر تطابق ندارد، این گروه auth با اتصال تطبیق داده نشده و نادیده گرفته می‌شود.

توجه داشته باشید که اگر الگوهای متعددی دارید که نمی‌توان آن‌ها را در الگوهای جامع‌تر ادغام کرد (مانند شمار زیادی از سیستم‌های منفرد پراکنده در شبکه که باید دسترسی داشته باشند)، ممکن است پارامتر hosts از حداکثر طول خط یعنی ۸٬۱۹۲ نویسه فراتر برود. در این صورت، لازم است آن گروه auth را به چندین گروه auth تفکیک کنید که هر کدام بخشی از میزبان‌ها را در پارامتر hosts خود قید کرده باشند و همگی یک هویت کاربری یکسان را تخصیص دهند.

در صورتی که این پارامتر ارائه نشود، تمامی میزبان‌ها مطابقت خواهند داشت.

اگر این پارامتر مشخص شده باشد، هر اتصالی که با این گروه auth تطابق پیدا کند، اختیارات و امتیازات خود را صرفاً از زیرمجموعه‌ای از گروه‌های access تعیین می‌کند که حاوی یک پارامتر key منطبق باشند.
فهرستی جداشده با کاما از الگوهای میزبان یا آدرس محلی با همان نحوی که در پارامتر hosts استفاده شده است. اگر این پارامتر قید شود، گروه auth آن تنها با اتصالاتی مطابقت خواهد داشت که به یک رابط شبکه محلی منطبق برقرار شده باشند. (بدیهی است که این پارامتر تنها برای سرورهایی با چندین رابط شبکه کاربرد دارد.)

در صورت عدم ارائه این پارامتر، تمام آدرس‌های محلی مطابقت داده می‌شوند.

مسیری به یک اسکریپت Perl برای تولید پویای یک گروه access. اگر یک گروه auth با موفقیت تطابق یابد و دارای پارامتر perl_access باشد، اسکریپت پرل داده‌شده در آرگومان برای ایجاد یک گروه access استفاده خواهد شد. این گروه سپس حقوق دسترسی کلاینت را تعیین کرده و تمامی گروه‌های access تعریف‌شده در readers.conf را نادیده می‌گیرد. صرفاً و تنها در حالتی که یک گروه auth موفق حاوی پارامتر perl_access باشد، گروه‌های access فایل readers.conf نادیده گرفته شده و حقوق کلاینت به صورت پویا معین می‌شود. این پارامتر تنها زمانی معتبر است که INN با پشتیبانی از Perl کامپایل شده باشد (دادن گزینه --with-perl به "configure"). اطلاعات بیشتر در فایل doc/hook-perl قابل دسترسی است.
مسیری به یک اسکریپت Perl برای احراز هویت. پارامتر perl_auth دقیقاً مشابه auth عمل می‌کند، با این تفاوت که اسکریپت نام‌برده را از طریق قلاب Perl و نه با یک برنامه خارجی فراخوانی می‌نماید. استفاده چندگانه/ترکیبی از پارامترهای auth، perl_auth و python_auth درون هر گروه auth مجاز است؛ هر خط به ترتیبی که نوشته شده آزموده خواهد شد. perl_auth قدرت بیشتری نسبت به auth دارد زیرا اطلاعات تکمیلی درباره کلاینت را در اختیار برنامه احراز هویت می‌گذارد و امکان بازگرداندن یک رشته خطا و یک نام کاربری را فراهم می‌کند. این پارامتر فقط زمانی معتبر است که INN با پشتیبانی Perl کامپایل شده باشد (--with-perl به "configure" ارسال شده باشد). اطلاعات تکمیلی در doc/hook-perl موجود است.
یک اسکریپت Python برای تولید پویای یک گروه access. اگر یک گروه auth با موفقیت تطابق پیدا کند و حاوی پارامتر python_access باشد، اسکریپت مشخص‌شده در آرگومان (بدون پسوند ".py" آن) واقع در دایرکتوری pathfilter برای ایجاد یک گروه access به کار گرفته می‌شود. این گروه سپس حقوق دسترسی کلاینت را معین کرده و بر تمام گروه‌های access در readers.conf تقدم می‌یابد.

تنها در حالتی که یک گروه auth منطبق حاوی پارامتر python_access باشد، گروه‌های access درون فایل readers.conf نادیده گرفته می‌شوند و حقوق کلاینت به شکل پویا تعیین می‌گردد.

این پارامتر تنها زمانی معتبر است که INN با پشتیبانی Python ساخته شده باشد (دادن --with-python به "configure"). اطلاعات بیشتر در فایل doc/hook-python ارائه شده است.

یک اسکریپت Python برای احراز هویت. پارامتر python_auth دقیقاً مشابه auth است، با این تفاوت که اسکریپت ارائه‌شده (بدون پسوند ".py" آن) واقع در دایرکتوری pathfilter را از طریق قلاب Python به جای یک برنامه خارجی اجرا می‌کند. استفاده چندگانه یا ترکیبی از پارامترهای auth، perl_auth و python_auth درون هر گروه auth مجاز است؛ هر خط به ترتیبی که در فایل آمده اجرا خواهد شد. python_auth توانایی‌های بالاتری نسبت به auth دارد زیرا اطلاعات بیشتری پیرامون کلاینت در اختیار برنامه احراز هویت می‌گذارد و امکان برگرداندن یک رشته خطا و یک نام کاربری را دارد.

این پارامتر تنها زمانی معتبر است که INN با پشتیبانی Python کامپایل شده باشد (ارسال --with-python به "configure"). اطلاعات بیشتر را می‌توانید در doc/hook-python بیابید.

یک اسکریپت Python برای اعمال پویای کنترل دسترسی بر اساس هر گروه خبری به طور جداگانه. اگر یک گروه auth موفقیت‌آمیز باشد و حاوی پارامتر python_dynamic باشد، اسکریپت داده‌شده (بدون پسوند ".py" آن) در دایرکتوری pathfilter، هر بار که کاربر قصد مشاهده یک گروه خبری یا خواندن یا ارسال مقاله را داشته باشد، برای تعیین حقوق کلاینت فراخوانی می‌شود. حقوق دسترسی تعیین‌شده توسط python_dynamic مقادیر پارامترهای گروه دسترسی از قبیل newsgroups، read و post را بازنویسی می‌کند.

این پارامتر تنها زمانی معتبر است که INN با پشتیبانی Python کامپایل شده باشد (دادن --with-python به "configure"). اطلاعات بیشتر در فایل doc/hook-python آمده است.

اگر مقدار آن برابر با true قرار داده شود، اتصال ورودی فقط در صورتی با این گروه auth تطابق پیدا می‌کند که رمزنگاری‌شده باشد؛ خواه از آغاز اتصال در صورت ارسال گزینه -S به nnrpd، خواه پس از اجرای موفق STARTTLS، یا پس از احراز هویت موفق با استفاده از یک مکانیزم SASL که لایه رمزنگاری را مذاکره می‌نماید. این پارامتر تنها زمانی معتبر است که INN با پشتیبانی TLS/SSL یا SASL کامپایل شده باشد (به طور پیش‌فرض اگر کتابخانه‌های SSL و crypto از OpenSSL یا کتابخانه Cyrus SASL در زمان پیکربندی یافت شوند؛ در غیر این صورت گزینه‌های --with-openssl و --with-sasl در "configure" را بررسی فرمایید).
یک خط فرمان ساده برای تحلیل‌گر کاربر (کاراکترهای متا در شل پشتیبانی نمی‌شوند). در صورت عدم ارائه مسیر کامل، برنامه اجرایی باید در دایرکتوری pathbin/auth/resolv قرار گرفته باشد. یک تحلیل‌گر (resolver) برنامه‌ای برای احراز هویت است که تلاش می‌کند هویت کاربر متصل را صرفاً با استفاده از داده‌های اتصال تشخیص دهد (به بیان دیگر، کاربر هنوز نام کاربری و گذرواژه‌ای وارد نکرده است). مثالی از یک تحلیل‌گر، برنامه‌ای است که هویت را از طریق بازخوانی مکانیزم ident یا از روی نام میزبان کاربر تشخیص می‌دهد.

یک گروه auth می‌تواند چندین پارامتر res داشته باشد که به ترتیب فهرست‌شدن آزموده خواهند شد. نتیجه حاصل از اولین موردی که با موفقیت اجرا شود ملاک قرار می‌گیرد.

به عنوان روشی جایگزین، می‌توان از یک بلوک res به جای پارامتر res استفاده نمود. پارامترهای معتبر در این بلوک‌های res عبارتند از:

رشته‌ای برای درج در فایل لاگ pathlog/news.notice (با پیشوند "res also-log:") پیش از آزمودن برنامه تحلیل‌گر. یک گروه res می‌تواند چندین پارامتر log داشته باشد که به ترتیب قیدشدن ثبت خواهند شد.
این پارامتر در یک بلوک res الزامی است. کاربرد آن دقیقاً مشابه پارامتر res است که مستقیماً در بلوک auth استفاده می‌شود. 
auth <auth-name> {
    res: <res-program>
}

بنابراین ساختار فوق معادل است با:

auth <auth-name> {
    res <res-name> {
        program: <res-program>
    }
}

مجموعه‌ای از حروف که مجوزهای اعطاشده به کلاینت را مشخص می‌کند. این حروف از مجموعه زیر انتخاب می‌شوند:
کلاینت می‌تواند مقالاتی با فیلد سرآیند Approved ارسال کند (به بیان دیگر، می‌تواند مقالات را برای گروه‌های خبری مدیریت‌شده و نیازمند تایید، تصویب کند). به طور پیش‌فرض این کار مجاز نیست.
کلاینت می‌تواند مقالات را با دستور IHAVE تزریق کند. دقت داشته باشید که برای تزریق مقالات با دستور IHAVE، کاربر باید مجوز POST (گزینه "P") را نیز دارا باشد. مقالاتی که با IHAVE تزریق می‌شوند مانند مقالات ارسال‌شده با POST در نظر گرفته می‌شوند؛ بدین معنا که این مقالات نباید پیش‌تر تزریق شده باشند (نباید دارای فیلدهای سرآیندی مانند Injection-Info باشند).
کلاینت می‌تواند در گروه‌های خبری که برای عدم پذیرش ارسال محلی تنظیم شده‌اند، پست ارسال کند (فیلدهای وضعیت "j"، "n" و "x" در فایل active(5)).
کلاینت می‌تواند از دستور NEWNEWS استفاده کند که تنظیمات سراسری سیستم را بازنویسی می‌نماید.
کلاینت اجازه ارسال مقاله (post) دارد.
کلاینت اجازه خواندن مقاله (read) دارد.

توجه داشته باشید که اگر این پارامتر تعریف شود، گزینه allownewnews در inn.conf برای اتصالات منطبق با این گروه access نادیده گرفته می‌شود و امکان استفاده کلاینت از دستور NEWNEWS تماماً به حضور نویسه "N" در رشته access بستگی دارد. اگر مایل به پشتیبانی از NEWNEWS هستید، مطمئن شوید که هنگام استفاده از این پارامتر، "N" را در رشته access قرار دهید.

همچنین اگر این پارامتر تعریف شود و حرف "R" در رشته access موجود نباشد، کلاینت فارغ از مقادیر پارامترهای newsgroups یا read امکان خواندن مقالات را نخواهد داشت. به همین ترتیب، اگر این پارامتر مشخص گردد و "P" در آن نباشد، کلاینت نمی‌تواند مقاله‌ای ارسال کند. این شیوه استفاده از پارامتر access منسوخ و گمراه‌کننده است؛ اکیداً توصیه می‌شود که در صورت استفاده از پارامتر access، حروف "R" و "P" همیشه در رشته access گنجانده شوند و برای کنترل دقیق دسترسی‌ها از پارامترهای newsgroups، read و post بهره گرفته شود. (برای اعطای دسترسی فقط‌خواندنی بدون امکان ارسال، می‌توانید صرفاً پارامتر read را بدون پارامتر post تعریف کنید.)

اگر روی "none" تنظیم شود، ارسال‌های این کاربران فاقد هش اختصاصی کاربر در فیلد سرآیند Cancel-Lock خواهند بود (فقط هش مدیر سرور تولید می‌شود). هیچ فیلد سرآیند Cancel-Key نیز در درخواست‌های لغو (cancel) یا جایگزینی (supersede) درج نخواهد شد. این یک مقدار متنی است و پیش‌فرض آن "username" می‌باشد؛ بدین معنا که یک هش اختصاصی بر اساس هویت تخصیص‌یافته به این اتصال تولید می‌گردد.

مقدار ممکن دیگر برای این پارامتر "ip" است، که در این حالت یک هش اختصاصی بر اساس آدرس IP اتصال به کار می‌رود (که باید یک IP ثابت باشد تا بتواند واقعاً هویت کاربران را مشخص سازد).

برای اطلاعات بیشتر در خصوص ساختار قفل لغو به inn-secrets.conf(5) مراجعه کنید. دلیل اصلی برای وجود این پارامتر، غیرفعال‌سازی این مکانیزم احراز هویت در مواقعی است که یک هویت یا آدرس IP یکسان توسط گروه access به چندین نفر مختلف اختصاص می‌یابد؛ در غیر این صورت، هر یک از این افراد می‌توانند درخواست لغو مقاله‌ای را ارسال کنند که در اصل توسط فرد دیگری با همان هویت یا آدرس IP ارسال شده بوده است.

در صورت تنظیم، مقدار این پارامتر به عنوان بخش دامنه (بخش سمت راست پس از علامت "@") در شناسه‌های Message-ID تولیدشده خودکار، و همچنین نام سرور قیدشده در فیلدهای سرآیند Injection-Info استفاده می‌شود.

به طور پیش‌فرض، مقدار این پارامتر از پارامتر هم‌نام آن در inn.conf به ارث می‌رسد. با این حال، اگر domain صریحاً در readers.conf مقداردهی نشده باشد، رفتار تشریح‌شده در بالا فعال نمی‌شود مگر اینکه پارامتر virtualhost بر روی true تنظیم گردد.

همچنین ممکن است بخواهید پارامتر fromhost (به ارث رسیده از inn.conf) را برای نشانی ثبت شکایات در فیلد سرآیند Injection-Info مشخص نمایید، در صورتی که مقدار پیش‌فرض آن نیاز به تغییر دارد و پارامتر complaints تنظیم نشده یا مقدار newsmaster فاقد "@" است.

این پارامتر آستانه‌ای را مشخص می‌کند که پایین‌تر از آن، nnrpd باید به جای ارائه یک مقدار تخمینی، تعداد دقیق مقالات موجود در گروه‌های خبری را گزارش دهد. تعداد دقیق مقالات معمولاً یک بار در روز در حین فرآیند منقضی‌سازی توسط expirover (که توسط news.daily فراخوانی می‌شود) به‌روزرسانی می‌گردد، و همچنین با ورود مقالات جدید آپدیت می‌شود، اما در روش‌های ذخیره‌سازی خود-منقضی‌شونده مانند CNFS با لغو یا بازنویسی مقالات لزوماً به‌روز نمی‌شود.

هنگامی که تعداد تخمینی مقالات اکیداً کمتر از groupexactcount باشد، nnrpd مقالات موجود را بازشماری کرده و عدد دقیق را بازمی‌گرداند. اگر groupexactcount روی "0" تنظیم شود، nnrpd همواره بازشماری دقیق انجام خواهد داد. اگر روی "1" تنظیم شود، هرگز بازشماری نخواهد کرد.

گرچه ارائه شمارش دقیق مقالات اجباری نیست، اما ممکن است برای تشخیص گروه‌های خبری خالی با نمایش عدد دقیق "0" به جای تخمین "1" بسیار سودمند باشد (در این وضعیت، کلاینت خبرخوان ممکن است نشان دهد ۱ مقاله در گروه موجود است، سپس تلاش به دریافت مقاله می‌کند و در نهایت هیچ پیامی به کاربر نشان نمی‌دهد).

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

این یک مقدار عددی صحیح است و پیش‌فرض آن "5" می‌باشد.

در صورت حضور این پارامتر، این گروه access تنها زمانی برای تعیین اختیارات کاربران در نظر گرفته می‌شود که کاربر با گروه auth دارای همین پارامتر key مطابقت یافته باشد.
اگر فیلدهای سرآیند Date یا Injection-Date در مقاله ارسالی وجود نداشته باشد، nnrpd معمولاً این فیلدها را در قالب زمان هماهنگ جهانی (UTC) درج می‌کند. اگر این پارامتر روی true تنظیم شود، فیلد سرآیند Date در قالب منطقه زمانی محلی درج خواهد شد. (با این حال، فیلد سرآیند Injection-Date طبق رفتار پارامتر addinjectiondate در inn.conf اضافه شده و در قالب UTC باقی خواهد ماند.) این یک پارامتر بولی است و پیش‌فرض آن false می‌باشد.

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

اگر این پارامتر تعریف شده باشد (و مقداری غیرصفر داشته باشد)، برای کد محدودسازی نرخ تبادل داده در nnrpd استفاده خواهد شد. کلاینت تنها با این حداکثر سرعت (بر حسب بایت در ثانیه) قادر به دانلود خواهد بود. توجه کنید که در صورت استفاده از لایه رمزنگاری، محدودسازی روی جریان داده پیش از رمزنگاری اعمال می‌شود.
کاربران منطبق با این گروه access مجاز به خواندن و ارسال مقاله در تمامی گروه‌های خبری مطابق با این فهرست جداشده با کاما از الگوهای وایلد‌مت هستند. یک رشته خالی معادل "newsgroups: *" است؛ اگر این پارامتر تعریف نشود، اتصال رد خواهد شد (مگر اینکه به جای آن از read و/یا post استفاده شده باشد).
به عنوان آدرس تماس در پیام راهنمای بازگردانده شده از nnrpd(8) به کار می‌رود، البته در صورتی که پارامتر virtualhost: روی true تنظیم شده باشد.
اگر روی false قرار گیرد، مقالات ارسالی این کاربران از فیلتر Perl عبور نخواهند کرد، حتی اگر این فیلتر در سیستم فعال باشد. این یک مقدار بولی است و پیش‌فرض آن true می‌باشد.
مشابه پارامتر newsgroups است، اما کلاینت فقط مجوز ارسال مقاله به گروه‌های خبری منطبق را پیدا می‌کند. این پارامتر عموماً در کنار read برای تفکیک الگوهای مجاز خواندن و ارسال به کار می‌رود (معمولاً برای اینکه کاربر اجازه خواندن گروه‌های بیشتری را نسبت به گروه‌های مجاز برای ارسال داشته باشد). این پارامتر نمی‌تواند همراه با پارامتر newsgroups در یک گروه access مشترک قرار گیرد.
اگر روی false قرار گیرد، مقالات ارسالی این کاربران از فیلتر Python عبور داده نمی‌شوند حتی اگر فیلتر فعال باشد. این مقدار بولی است و پیش‌فرض آن true می‌باشد.

این پارامتر در حال حاضر تاثیری ندارد زیرا فیلترینگ Python هنوز در nnrpd پیاده‌سازی نشده است. اگر مایل به فیلتر کردن مقالات با Python هستید، باید از سازوکار تعبیه‌شده در innd بهره ببرید.

مشابه پارامتر newsgroups است، اما کلاینت صرفاً مجوز خواندن مقالات در گروه‌های خبری منطبق را پیدا می‌کند. این پارامتر اغلب همراه با post برای تعریف گروه‌های فقط‌خواندنی به کار می‌رود؛ این گزینه نمی‌تواند با پارامتر newsgroups در یک گروه access قرار گیرد. (اگر از read استفاده شود و پارامتر post وجود نداشته باشد، کلاینت دسترسی کاملاً فقط‌خواندنی خواهد داشت.)
اگر این پارامتر تنظیم شده باشد، اتصال کلاینت منطبق با این بلوک با ارسال پیام "Permission denied" حاوی متن این پارامتر (یک رشته بیانگر دلیل) قطع خواهد شد. برخی کلاینت‌های خبرخوان این دلیل را به کاربر نمایش می‌دهند.
اگر مقدار آن true باشد، فیلد سرآیند Path ارائه‌شده توسط کاربر در مقاله ارسالی حذف می‌شود به جای اینکه در آغاز فیلد سرآیند Path مقاله قرار گیرد. این یک مقدار بولی است و پیش‌فرض آن false می‌باشد.
امتیازات ارائه‌شده توسط این گروه access برای هر هویت کاربری که با این فهرست جداشده با کاما از الگوهای وایلد‌مت مطابقت داشته باشد اعمال می‌گردد. اگر این پارامتر مشخص نشود، گروه access به تمام کاربران اختصاص می‌یابد (و اساساً معادل "users: *" است).
این پارامتر را روی true تنظیم کنید تا nnrpd به گونه‌ای عمل کند که گویی روی سروری با نامی متفاوت از نام اصلی خود در حال اجراست. در این وضعیت پارامتر domain باید یا در inn.conf یا در همین گروه access مقداردهی شده باشد. بدنه فیلد سرآیند Xref تمامی مقالات و اطلاعات نمای کلی (overview) ارائه‌شده به کلاینت‌ها تغییر خواهد کرد تا چنین به نظر برسد که از سرور تعیین‌شده در domain هستند، و مقالات ارسالی نیز از آن نام سرور در بدنه‌های سرآیند Message-ID و Injection-Info استفاده خواهند نمود. (علاوه بر این، اگر پرچم -I به nnrpd ارسال شده باشد، به برنامه‌های ارسال‌کننده پیشنهاد می‌شود شناسه‌های Message-ID حاوی رشته ارائه‌شده با -I تولید کنند.)

به طور مشابه، فیلدهای سرآیند Path که به کلاینت‌ها نمایش داده شده یا در مقالات ارسالی درج می‌گردند، از مقدار domain استفاده خواهند کرد (اگر pathhost در گروه access تنظیم نشده باشد یا مقداری همسان با inn.conf داشته باشد) یا از مقدار pathhost استفاده می‌کنند (اگر pathhost در گروه access روی مقداری متفاوت از inn.conf تنظیم شده باشد).

همچنین، بخش دامنه (سمت راست پس از علامت "@") در نشانی ایمیل newsmaster که در پیام راهنمای بازگردانده‌شده از nnrpd ذکر می‌شود، در صورتی که newsmaster فاقد بخش دامنه باشد، از مقدار domain استفاده خواهد کرد.

حداقل یکی از پارامترهای domain یا pathhost در گروه access باید مقداری متمایز از inn.conf داشته باشد، در غیر این صورت nnrpd با خطا متوقف شده و شروع به کار نخواهد کرد.

توجه داشته باشید که فعال کردن این پارامتر سرور را ملزم می‌سازد تمامی مقالات را پیش از ارائه به کلاینت اصلاح کند، که ممکن است کارایی سیستم را تا حدی کاهش دهد.

به علاوه، تمامی پارامترهای زیر در گروه‌های access معتبر هستند و تنظیمات سراسری در inn.conf را بازنویسی می‌نمایند. برای مشاهده توضیحات این پارامترها به inn.conf(5) رجوع کنید:

addinjectiondate, addinjectionpostingaccount,
addinjectionpostinghost, backoff_auth, backoff_db, backoff_k,
backoff_postfast, backoff_postslow, backoff_trigger,
checkincludedtext, clienttimeout, complaints, fromhost,
localmaxartsize, moderatormailer, nnrpdauthsender, nnrpdcheckart,
nnrpdoverstats, nnrpdposthost, nnrpdpostport, organization,
pathhost, readertrack, spoolfirst, strippostcc.

در اینجا خلاصه‌ای از مراحلی که هنگام برقراری اتصال یک کلاینت رخ می‌دهد آمده است:

  • تمامی گروه‌های auth پیمایش می‌شوند و گروه‌هایی که با شرایط کلاینت مطابقت ندارند (به دلیل عدم تطابق hosts، localaddress، require_encryption و غیره) کنار گذاشته می‌شوند.
  • گروه‌های auth باقی‌مانده از انتها به ابتدا بررسی می‌شوند و تلاش می‌شود بر اتصال جاری اعمال گردند. این امر شامل اجرای برنامه‌های res در صورت تعریف شدن، و در غیر این صورت اعمال مقدار default است. نخستین گروه auth (از پایین فایل) که یک کاربر معتبر بازگرداند، به عنوان گروه auth فعال برگزیده می‌شود.
  • اگر هیچ گروه auth کاربر معتبری ارائه ندهد (هیچ‌یک دارای پارامتر default نبوده و برنامه res موفقی نداشته باشند) اما برخی از گروه‌های auth دارای خطوط auth باشند (که بیانگر احتمال احراز هویت کاربر و کسب مجوز در مراحل بعدی است)، اتصال فاقد گروه auth معتبر تلقی می‌گردد (بدین معنا که گروه‌های access به کلی نادیده گرفته می‌شوند)، اما اتصال قطع نمی‌شود. در عوض، کد وضعیت ۴۸۰ (به معنای نیاز به احراز هویت) برای تمام درخواست‌ها ارسال می‌شود تا زمانی که کاربر هویت خود را احراز نماید.
  • هنگامی که کاربر احراز هویت می‌کند، گروه‌های auth مجدداً بررسی می‌شوند و صرفاً گروه‌های منطبقی که حداقل دارای یک خط auth، perl_auth یا python_auth باشند مد نظر قرار می‌گیرند. این گروه‌های auth از انتها به ابتدا بررسی شده و برنامه‌های auth و اسکریپت‌های perl_auth یا python_auth اجرا می‌شوند. نخستین گروه auth (از پایین فایل) که یک کاربر معتبر بازگرداند، به عنوان گروه auth فعال انتخاب می‌گردد.
  • صرف‌نظر از اینکه گروه auth چگونه تعیین شده باشد، به محض برقراری گروه، از آن برای انتساب هویت کاربر با استفاده از خروجی موفق خط res، auth، perl_auth یا python_auth (یا در صورت لزوم مقدار default)، و افزودن default-domain در صورت نیاز، استفاده می‌شود. (در حالتی که پارامتر perl_access یا python_access وجود داشته باشد.)
  • در نهایت، با پیمایش گروه‌های access از پایین به بالا و یافتن نخستین تطابق، یک گروه access انتخاب می‌گردد. (اگر گروه auth تعیین‌شده حاوی یک خط perl_access یا python_access باشد، گروه access تولیدشده به شکل پویا توسط اسکریپت جایگزین می‌گردد.) سپس دسترسی‌ها و اختیارات کاربر بر پایه گروه access انتخاب‌شده به او داده می‌شود.

شاید ساده‌ترین مثال کاربردی از یک فایل کامل readers.conf این باشد که به تمامی اتصالات از دامنه "example.com"، به جز دستگاه باب (Bob)، دسترسی خواندن و ارسال مقاله در تمامی گروه‌ها داده شود و هیچ دسترسی برای اتصالات سایر مبداها برقرار نگردد:

auth example.com {
    hosts: "*.example.com, example.com, !bob.example.com"
    default: "<EXAMPLE>"
}
access full {
    users: "<EXAMPLE>"
    newsgroups: *
    addcanlockuser: none
}

توجه داشته باشید که قلمرو دسترسی فوق می‌توانست بدون کلید users نیز نوشته شود، که در آن صورت برای هر هویت کاربری اعمال می‌شد (هرچند در این مثال، هویت کاربری اختصاص‌یافته به تمام اتصالات منطبق "<EXAMPLE>" خواهد بود). با این حال توصیه می‌شود یک کلید صریح users درج گردد تا مشخص باشد بلوک دسترسی دقیقاً برای چه کسانی اعمال می‌شود.

از آنجا که تنها قلمرو auth تعریف‌شده صرفاً با میزبان‌های دامنه "example.com" تطابق دارد، اتصالات سایر میزبان‌ها بلافاصله رد خواهند شد.

اگر سیستم‌هایی دارید که فقط باید دسترسی خواندن به سرور داشته باشند، می‌توانید مثال بالا را با افزودن یک گروه auth و access دیگر اندکی تغییر دهید:

auth lab {
    hosts: "*.lab.example.com"
    default: <LAB>
}
access lab {
    users: <LAB>
    read: *
}

اگر این تعاریف پس از مثال قبلی در فایل قرار گیرند، برای هر کاربری که از دستگاهی در دامنه lab.example.com متصل شود تقدم خواهند داشت (چرا که در جایگاه پایین‌تری در فایل قرار گرفته‌اند)، و همه صرفاً دسترسی خواندن خواهند داشت و امکان ارسال نخواهند داشت.

در اینجا مثالی مشابه برای یک سرور خبری آورده شده است که اتصالات را از هر کجایی می‌پذیرد اما کاربر را ملزم به وارد کردن نام کاربری و گذرواژه می‌سازد. نام کاربری و گذرواژه ابتدا در یک پایگاه‌داده خارجی بررسی شده و سپس از PAM استفاده می‌شود:

auth all {
    auth: "ckpasswd -f <pathdb in inn.conf>/newsusers"
    auth: ckpasswd
}
access full {
    users: *
    newsgroups: *
}

هنگامی که کاربر برای نخستین بار متصل می‌شود، هیچ کلید res و هیچ مقدار پیش‌فرضی وجود ندارد، بنابراین هیچ هویت معتبری دریافت نمی‌کند و اتصال با هیچ گروه دسترسی (حتی گروه‌های دارای "users: *") تطابق نخواهد یافت. چنین کاربرانی تا زمانی که احراز هویت ننمایند، تنها پاسخ‌های "نیاز به احراز هویت" از nnrpd دریافت خواهند کرد.

اگر آن‌ها بعداً احراز هویت کنند، نام کاربری و گذرواژه ابتدا با اجرای ckpasswd با گزینه -f روی یک فایل خارجی از گذرواژه‌های رمزنگاری‌شده بررسی می‌شود و سپس از PAM (در صورت کامپایل شدن INN با پشتیبانی PAM) برای اعتبارسنجی گذرواژه بهره می‌برد (و در صورت شکست، گذرواژه در برابر فیلد گذرواژه بازگردانده‌شده از getpwnam(3) بررسی می‌گردد). اگر هر دوی آن‌ها ناموفق باشند، کاربر همچنان فاقد هویت خواهد بود؛ در غیر این صورت، یک هویت به او تخصیص می‌یابد (معمولاً همان نام کاربری ارائه‌شده با دامنه‌ای در صورت تعریف، هرچند یک احراز هویت‌کننده از نظر فنی می‌تواند هویتی کاملاً متفاوت تعیین کند)، و گروه access با آن تطابق یافته و دسترسی کامل اعطا می‌شود.

بررسی چگونگی ترکیب مثال‌های بالا می‌تواند آموزنده باشد؛ گروه‌های عمومی همواره در ابتدا قرار می‌گیرند. ترتیب گروه‌های auth در عمل تفاوتی ایجاد نمی‌کند، چرا که گروه "hosts: example.com" تنها پیش از ارسال نام کاربری/گذرواژه اعمال می‌شود و گروه "auth: ckpasswd" صرفاً پس از آن تطابق دارد؛ ترتیب فقط در حالتی اهمیت داشت که هر دو گروه برای هر دو وضعیت صدق می‌کردند. اما ترتیب گروه‌های access در این سناریو حائز اهمیت است، به شرطی که خطوط newsgroups تفاوت داشته باشند؛ گروه access بدون خط users باید در ابتدا قرار گیرد و گروه دارای "users: <LOCAL>" پس از آن بیاید.

در اینجا نمونه‌ای از یک حالت متداول دیگر ارائه شده است: سروری که فقط به اتصالات یک دامنه محلی اجازه اتصال می‌دهد و یک سلسله‌مراتب اضافی دارد که دسترسی به آن نیازمند گذرواژه است.

auth "example.com" {
    hosts: "*.example.com"
    auth: "ckpasswd -f <pathdb in inn.conf>/newsusers"
    default: "anonymous"
}
access regular {
    newsgroups: "*,!example.restricted.*"
    addcanlockuser: none
}
access full {
    users: "*,!anonymous"
    newsgroups: *
}

در این مثال، کاربران احراز هویت‌نشده هویت "anonymous" را دریافت می‌کنند که تنها با اولین گروه access تطابق دارد و در نتیجه دسترسی به سلسله‌مراتب "example.restricted.*" دریافت نمی‌کند. برای کاربران ناشناس نباید هیچ عنصر اختصاصی در Cancel-Lock تولید شود. هر کاربری که با گذرواژه موجود در فایل newsusers احراز هویت کند، دسترسی کامل به تمامی گروه‌ها را به دست می‌آورد. با این وجود توجه کنید که تنها بلوک احراز هویت به نام‌های میزبان در دامنه example.com محدود شده است؛ اتصالات خارج از آن دامنه هرگز اجازه دسترسی نیافته و فرصتی برای احراز هویت نیز نخواهند داشت.

در اینجا یک مثال بسیار جامع‌تر آورده شده است. این سناریو برای سازمانی است که سلسله‌مراتب داخلی "example.*" را صرفاً در اختیار کاربران پوسته (shell) محلی روی دستگاه‌هایی می‌گذارد که به identd(8) آن‌ها می‌توان اطمینان کرد. کاربران Dialup باید نام کاربری و گذرواژه‌ای وارد کنند که در برابر RADIUS ارزیابی می‌شود. کاربران دوردست باید نام کاربری و گذرواژه‌ای ارائه دهند که با پایگاه‌داده سرور اخبار اعتبارسنجی می‌شود. در نهایت، کارمندان مدیر سیستم (کاربران "joe" و "jane") می‌توانند در همه جا پست ارسال کنند (شامل گروه‌های "example.admin.*" که برای بقیه فقط‌خواندنی است)، و از فیلتر Perl معاف هستند. به عنوان یک قابلیت تکمیلی، در ارسال‌های کاربران dialup، فیلد سرآیند Sender با هویت احراز هویت‌شده آن‌ها جایگزین می‌گردد.

از آنجا که این سازمان دارای چند گروه خبری مدیریت‌شده (moderated) داخلی است، کادر مدیریت همچنین می‌توانند پیام‌هایی با سرآیند Approved ارسال کنند، اما کاربران عادی این امکان را ندارند.

auth default {
    auth: "ckpasswd -f <pathdb in inn.conf>/newsusers"
    default: <FAIL>
    default-domain: example.com
}
auth shell {
    hosts: *.shell.example.com
    res: ident
    auth: ckpasswd
    default: <FAIL>
    default-domain: shell.example.com
}
auth dialup {
    hosts: *.dialup.example.com
    auth: radius
    default: <FAIL>
    default-domain: dialup.example.com
}
access shell {
    users: *@shell.example.com
    read: *
    post: "*, !example.admin.*"
}
access dialup {
    users: *@dialup.example.com
    newsgroups: *,!example.*
    nnrpdauthsender: true
}
access other {
    users: "*@example.com, !<FAIL>@example.com"
    newsgroups: *,!example.*
}
access fail {
    users: "<FAIL>@*"
    newsgroups: !*
}
access admin {
    users: "joe@*,jane@*"
    newsgroups: *
    access: "RPA"
    perlfilter: false
}

به استفاده از دامنه‌های گوناگون برای تفکیک ساده کاربران dialup از کاربران shell توجه کنید. روش دیگر برای این کار استفاده از پارامترهای key بود، اما این شیوه رشته‌های هویتی ملموس‌تری ایجاد می‌کند. همچنین توجه داشته باشید که گروه دسترسی fail نه تنها اتصالات ناموفق کاربران خارجی را مهار می‌کند، بلکه اتصالات ناموفق کاربران shell و dialup را نیز پیش از احراز هویت پوشش می‌دهد. برای نمونه رشته هویتی تخصیص‌یافته به کاربران dialup پیش از احراز هویت RADIUS، هم با گروه دسترسی dialup و هم با گروه fail همخوانی دارد (زیرا رشته "<FAIL>@dialup.example.com" است)، اما از آنجا که گروه fail در انتها قرار دارد، تقدم پیدا می‌کند.

گروه auth مربوط به shell دارای یک پارامتر auth است تا کاربران "joe" و "jane" بتوانند در صورت تمایل، از احراز هویت نام کاربری و گذرواژه برای دستیابی به امتیازات ویژه خود استفاده کنند حتی اگر با حسابی دیگر در ماشین‌های shell وارد شده باشند (یا اگر سرویس ident کار نکند). هنگامی که آن‌ها برای نخستین بار متصل می‌شوند، دسترسی پیش‌فرض آن حساب کاربری را دارند، اما می‌توانند احراز هویت کنند تا دسترسی‌های گسترده خود را به دست آورند.

همچنین دقت کنید که اگر کاربران "joe" و "jane" از حساب‌های شخصی خود استفاده کنند، امتیازات ویژه خود را بدون در نظر گرفتن شیوه اتصال (خواه از طریق dialup، ماشین‌های shell یا حتی از راه دور با نام کاربری و گذرواژه) به دست خواهند آورد.

در نهایت، در اینجا یک نمونه بسیار ساده از پیکربندی برای یک سرور عمومی برای یک سلسله‌مراتب خبری مشخص آورده شده است.

auth default {
    hosts: *
    default: <PUBLIC>
}
access default {
    users: <PUBLIC>
    newsgroups: example.*
    addcanlockuser: none
}

دقت فرمایید که کلاینت‌ها مجاز به خواندن هیچ گروه دیگری نیستند؛ این محدودیت صرفاً به عنوان یک اقدام احتیاطی برای جلوگیری از دسترسی آن‌ها به گروه‌های مدیریتی یا خواندن پیام‌های کنترلی اعمال شده است. هنگام اجرای چنین سرور عمومی، در نظر داشته باشید که بسیاری از سلسله‌مراتب‌های عمومی ممکن است بعداً دریافت شده و مجدداً به شبکه اصلی یوزنت تزریق شوند؛ بنابراین اکیداً توصیه می‌شود که یک فیلتر Perl یا Python برای رد کردن هرگونه پیام ارسال متقابل (crosspost) شده به خارج از سلسله‌مراتب محلی شما و همچنین پیام‌های حاوی سرآیند Supersedes اجرا کنید. این کار مانع از آن می‌شود که پیام‌های ارسال‌شده در سلسله‌مراتب عمومی شما در صورت درز به بیرون، به سایر بخش‌های شبکه یوزنت لطمه وارد سازند.

برای حالت‌های پیچیده‌تر، یا اگر صرفاً ترجیح می‌دهید از یک پایگاه‌داده برای نگهداری اطلاعات احراز هویت و/یا مجوزدهی استفاده نمایید، می‌توانید از اسکریپت‌های Perl یا Python برای احراز هویت پویای کاربران و/یا ایجاد بلوک‌های دسترسی آن‌ها بهره بگیرید. آنگاه می‌توانید تمامی اطلاعات مرتبط (کاربر، گذرواژه، گروه‌های خبری مجاز برای خواندن، گروه‌های خبری مجاز برای ارسال و غیره) را برای نمونه در یک پایگاه‌داده SQLite قرار داده و از یک اسکریپت nnrpd_auth.pl یا nnrpd_auth.py برای احراز هویت کاربران، و/یا یک اسکریپت nnrpd_access.pl یا nnrpd_access.py برای اعطای دسترسی استفاده فرمایید. در این صورت، در readers.conf تنها کافی است تعریف زیر را بگنجانید:

auth checkcredentials {
    perl_auth: "/path/to/script/nnrpd_auth.pl"
    perl_access: "/path/to/script/nnrpd_access.pl"
}

یا:

auth checkcredentials {
    python_auth: "nnrpd_auth"
    python_access: "nnrpd_access"
}

مزیت این اسکریپت‌های خارجی در این است که می‌توانید هر قاعده‌ای را که مایلید برنامه‌نویسی کنید، احتمالاً بر مبنای یک پایگاه‌داده مشترک بین سرویس خبری شما و سایر سرویس‌هایی که به کاربران خود ارائه می‌دهید. مدیریت صدها یا هزاران کاربر با اسکریپت‌های خارجی بسیار ساده‌تر از به‌کارگیری بلوک‌های ثابت readers.conf و یک فایل متنی ساده (flat file) برای اعتبارسنجی تک‌تک کاربران است.

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

احراز هویت با استفاده از دستورات AUTHINFO USER/PASS به صورت رمزنگاری‌نشده در بستر شبکه منتقل می‌گردد. بنابراین باید به ویژه در مورد گذرواژه‌های سیستمی (مانند "auth: ckpasswd -s") نهایت احتیاط به کار گرفته شود. گذرواژه‌ها را می‌توان با استفاده از پروتکل NNTP بر روی TLS/SSL یا از طریق تونل‌های ssh محافظت نمود، و این استفاده را می‌توان با یک پیکربندی اصولی سرور الزامی کرد تا تنها گروه‌های auth خاصی در شرایط امن اعمال شوند. همچنین می‌توان از مکانیزم‌های قدرتمند SASL برای احراز هویت بهره برد. چند توصیه در این زمینه:

  • برای محدود ساختن اتصالات روی پورت استاندارد NNTP (پورت ۱۱۹) به استفاده از لایه رمزنگاری جهت تطابق برخی (یا تمامی) گروه‌های auth، از پارامتر require_encryption استفاده کنید. دقت داشته باشید که یک کلاینت می‌تواند از STARTTLS برای مذاکره بر سر یک اتصال رمزنگاری‌شده TLS استفاده نماید. همچنین می‌توان در حین احراز هویت با AUTHINFO SASL یک لایه امن را مذاکره کرد.
  • اگر شبکه محلی خود را امن می‌دانید (اما نه اینترنت را)، می‌توانید گروه‌های auth با پارامتر محدودکننده hosts تعریف کنید؛ این گروه‌ها در بالای فایل قرار می‌گیرند و گروه‌های با دامنه شمول سراسری در پایین‌تر قرار خواهند گرفت.
  • اجرای nnrpd را همراه با پرچم -S (چه در حالت دیمن با -D، یا از طریق سوپرسرورهایی نظیر inetd) روی پورت NNTPS (پورت ۵۶۳) برای کلاینت‌هایی که از TLS/SSL پشتیبانی می‌کنند در نظر بگیرید. برای جزئیات نحوه پیکربندی به nnrpd(8) رجوع کنید. شما می‌توانید از پارامتر require_encryption یا فلگ -c برای مشخص ساختن یک فایل readers.conf مجزا در این سناریو بهره ببرید.
  • اگر می‌خواهید یک گروه auth را محدود نمایید تا صرفاً با اتصالات لوپ‌بک (loopback) مطابقت پیدا کند (برای کاربرانی که خبرخوان را روی localhost اجرا می‌کنند یا از طریق تونل ssh متصل شده‌اند)، از پارامتر localaddress استفاده نمایید.

نوشته‌شده توسط Aidan Cully <aidan@panix.com> برای InterNetNews. به طور عمده توسط Russ Allbery <eagle@eyrie.org> بازنویسی و گسترش یافته است.

auth_krb5(8), ckpasswd(8), inn.conf(5), innd(8), inn-secrets.conf(5), libinn_uwildmat(3), newsfeeds(5), nnrpd(8).

2025-03-29 INN 2.7.4