نام (NAME)

slapd.access - پیکربندی دسترسی برای slapd، دیمن مستقل LDAP

خلاصه دستور (SYNOPSIS)

/etc/openldap/slapd.conf

توضیحات (DESCRIPTION)

فایل slapd.conf(5) شامل اطلاعات پیکربندی برای دیمن slapd(8) است. این فایل پیکربندی همچنین توسط ابزارهای SLAPD شامل slapacl(8)، slapadd(8)، slapauth(8)، slapcat(8)، slapdn(8)، slapindex(8)، slapmodify(8) و slaptest(8) استفاده می‌شود.

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

قالب کلی slapd.conf به صورت زیر است:

# comment - these options apply to every database
<global configuration options>
# first database definition & configuration options
database    <backend 1 type>
<configuration options specific to backend 1>
# subsequent database definitions & configuration options
...

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

اگر هیچ کنترل دسترسی‌ای وجود نداشته باشد، خط‌مشی پیش‌فرض به همگان اجازه خواندن همه‌چیز را می‌دهد اما به‌روزرسانی‌ها را به rootdn محدود می‌سازد (مانند "access to * by * read").

هنگام کار با یک فهرست دسترسی، از آنجا که فهرست دسترسی سراسری عملاً به انتهای فهرست هر پایگاه‌داده ضمیمه می‌شود، در صورت خالی نبودن فهرست حاصل، فهرست دسترسی با یک دستورالعمل ضمنی access to * by * none پایان می‌یابد. اگر هیچ دستورالعمل دسترسی قابل اعمالی برای یک بک‌اند وجود نداشته باشد، خواندن پیش‌فرض (default read) اعمال می‌شود.

هشدار: rootdn همواره می‌تواند همه‌چیز را بخواند و بنویسد!

برای مدخل‌هایی که در هیچ بک‌اندی نگهداری نمی‌شوند (مانند یک root DSE)، دستورالعمل‌های سراسری استفاده می‌شوند.

آرگومان‌هایی که باید با متن واقعی جایگزین شوند درون براکت‌های <> نشان داده شده‌اند.

دستورالعمل دسترسی (THE ACCESS DIRECTIVE)

ساختار دستورالعمل‌های کنترل دسترسی به صورت زیر است:

access to <what> [ by <who> [ <access> ] [ <control> ] ]+

اعطای دسترسی (مشخص‌شده با <access>) به مجموعه‌ای از مدخل‌ها و/یا صفت‌ها (مشخص‌شده با <what>) توسط یک یا چند درخواست‌کننده (مشخص‌شده با <who>).

فهرست‌های دستورالعمل‌های دسترسی به ترتیبی که در slapd.conf آمده‌اند ارزیابی می‌شوند. هنگامی که یک بند <what> با داده‌ای که دسترسی به آن در حال ارزیابی است مطابقت کند، فهرست بندهای <who> آن بررسی می‌شود. هنگامی که یک بند <who> با ویژگی‌های درخواست‌کننده دسترسی مطابقت کند، بندهای <access> و <control> آن ارزیابی می‌شوند.

بررسی کنترل دسترسی در اولین تطابق بندهای <what> و <who> متوقف می‌شود، مگر آنکه توسط بند <control> به‌گونه دیگری تعیین شده باشد. هر فهرست بند <who> به‌طور ضمنی با یک بند

by * none stop

<control> خاتمه می‌یابد. این بند <control> ضمنی، ارزیابی دستورالعمل دسترسی را متوقف می‌کند و هیچ امتیاز دسترسی دیگری به فرد دیگری اعطا نمی‌شود. برای اینکه ارزیابی دستورالعمل دسترسی تنها زمانی که هر دوی <who> و <what> تطابق یافتند متوقف شود، یک بند صریح

by * break

را به انتهای فهرست بندهای <who> اضافه کنید.

هر فهرست بند <what> به‌طور ضمنی با بند

access to *
	by * none

خاتمه می‌یابد که موجب عدم اعطای هرگونه امتیاز دسترسی به داده‌ای می‌شود که وضعیت آن مشخص نشده است.

فیلد <WHAT> (THE <WHAT> FIELD)

فیلد <what> موجودیتی را مشخص می‌کند که دستورالعمل کنترل دسترسی به آن اعمال می‌شود. این فیلد می‌تواند قالب‌های زیر را داشته باشد:

dn[.<dnstyle>]=<dnpattern>
filter=<ldapfilter>
attrs=<attrlist>[ val[/matchingRule][.<attrstyle>]=<attrval>]

همراه با

<dnstyle>={{exact|base(object)}|regex
	|one(level)|sub(tree)|children}
<attrlist>={<attr>|[{!|@}]<objectClass>}[,<attrlist>]
<attrstyle>={{exact|base(object)}|regex
	|one(level)|sub(tree)|children}

عبارت dn=<dnpattern> مدخل‌ها را بر اساس زمینه نام‌گذاری‌شان (naming context) انتخاب می‌کند. <dnpattern> یک نمایش رشته‌ای از DN مدخل است. نویسه عام * نشان‌دهنده تمام مدخل‌ها است و در صورتی که هیچ فرمی از dn داده نشده باشد، به صورت ضمنی در نظر گرفته می‌شود.

مشخصه <dnstyle> اختیاری است؛ با این حال، توصیه می‌شود برای جلوگیری از ابهام آن را مشخص کنید. Base (مترادف baseObject)، حالت پیش‌فرض، یا exact (نام مستعار base) نشان‌دهنده مدخلی است که DN آن برابر با <dnpattern> باشد؛ one (مترادف onelevel) نشان‌دهنده تمام مدخل‌های بلافاصله در زیر <dnpattern> است؛ sub (مترادف subtree) نشان‌دهنده تمام مدخل‌های موجود در زیردرخت در <dnpattern> است؛ children نشان‌دهنده تمام مدخل‌های زیر (تابعِ) <dnpattern> است.

اگر توصیف‌کننده <dnstyle> برابر با regex باشد، آن‌گاه <dnpattern> یک الگوی عبارت منظم POSIX (از نوع «extended») است، همان‌گونه که در regex(7) و/یا re_format(7) شرح داده شده است، که با یک نمایش رشته‌ای نرمال‌شده از DN مدخل تطابق می‌یابد. قالب regex این الگو (هنوز) از UTF-8 پشتیبانی نمی‌کند.

عبارت filter=<ldapfilter> مدخل‌ها را بر اساس یک فیلتر معتبر LDAP، همان‌طور که در RFC 4515 توصیف شده است، انتخاب می‌کند. اگر هیچ قالبی از filter داده نشده باشد، فیلتر (objectClass=*) به‌طور ضمنی در نظر گرفته می‌شود.

عبارت attrs=<attrlist> صفت‌هایی را انتخاب می‌کند که قاعده کنترل دسترسی به آن‌ها اعمال می‌شود. این یک فهرست جداشده با کاما از انواع صفت‌ها به همراه نام‌های ویژه entry، نشان‌دهنده دسترسی به خود مدخل، و children، نشان‌دهنده دسترسی به فرزندان مدخل است. نام‌های ObjectClass نیز می‌توانند در این فهرست مشخص شوند که بر تمام صفت‌های الزامی و/یا مجاز توسط آن objectClass تأثیر می‌گذارند. در واقع، نام‌های موجود در <attrlist> که دارای پیشوند @ هستند، مستقیماً به عنوان نام‌های objectClass در نظر گرفته می‌شوند. نامی که دارای پیشوند ! باشد نیز به عنوان یک objectClass در نظر گرفته می‌شود، اما در این حالت قاعده دسترسی بر صفت‌هایی تأثیر می‌گذارد که توسط آن objectClass نه الزامی هستند و نه مجاز. اگر هیچ فرمی از attrs داده نشود، attrs=@extensibleObject به‌طور ضمنی در نظر گرفته می‌شود، یعنی تمام صفت‌ها را شامل می‌شود.

استفاده از قالب attrs=<attr> val[/matchingRule][.<attrstyle>]=<attrval> دسترسی به یک مقدار خاص از یک صفت منفرد را مشخص می‌کند. در این حالت، تنها یک نوع صفت منفرد می‌تواند تعیین شود. <attrstyle> مقدار exact (پیش‌فرض) از قاعده تطابق برابری (equality matching rule) صفت برای مقایسه مقدار استفاده می‌کند، مگر آنکه یک قاعده تطابق متفاوت (و سازگار) مشخص شده باشد. اگر <attrstyle> برابر با regex باشد، مقدار ارائه‌شده به عنوان یک الگوی عبارت منظم POSIX (از نوع «extended») استفاده می‌شود. اگر صفت دارای نحو DN باشد، <attrstyle> می‌تواند هر یک از base، onelevel، subtree یا children باشد که به ترتیب منجر به تطابق base، onelevel، subtree یا children می‌شود.

عبارت‌های dn، filter و attrs تجمیعی هستند؛ آن‌ها می‌توانند به صورت متوالی برای انتخاب موجودیت‌هایی که قاعده دسترسی به آن‌ها اعمال می‌شود، بر اساس زمینه نام‌گذاری، مقدار و نوع صفت به‌طور هم‌زمان استفاده شوند. زیرتطابق‌های حاصل از تطابق regex می‌توانند در فیلد <who> با استفاده از نحو ${v<n>}، که در آن <n> شماره زیرتطابق است، مورد ارجاع قرار گیرند. نحو پیش‌فرض، $<n>، در واقع یک نام مستعار برای ${d<n>} است که متناظر با ارجاع به زیرتطابق‌های حاصل از بخش dnpattern در فیلد <what> می‌باشد.

بخش <WHO> (THE <WHO> FIELD)

فیلد <who> مشخص می‌کند که قوانین دسترسی برای چه کسانی اعمال می‌شوند. چندین عبارت <who> می‌توانند در یک دستور کنترل دسترسی قرار گیرند، که بیانگر امتیازات دسترسی متفاوت به یک منبع یکسان برای دسترسی‌گیرندگان مختلف است. این فیلد می‌تواند به اشکال زیر باشد:

*
anonymous
users
self[.<selfstyle>]
dn[.<dnstyle>[,<modifier>]]=<DN>
dnattr=<attrname>
realanonymous
realusers
realself[.<selfstyle>]
realdn[.<dnstyle>[,<modifier>]]=<DN>
realdnattr=<attrname>
group[/<objectclass>[/<attrname>]]
	[.<groupstyle>]=<group>
peername[.<peernamestyle>]=<peername>
sockname[.<style>]=<sockname>
domain[.<domainstyle>[,<modifier>]]=<domain>
sockurl[.<style>]=<sockurl>
set[.<setstyle>]=<pattern>
ssf=<n>
transport_ssf=<n>
tls_ssf=<n>
sasl_ssf=<n>
dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]

با مقادیر:

<style>={exact|regex|expand}
<selfstyle>={level{<n>}}
<dnstyle>={{exact|base(object)}|regex
	|one(level)|sub(tree)|children|level{<n>}}
<groupstyle>={exact|expand}
<peernamestyle>={<style>|ip|ipv6|path}
<domainstyle>={exact|regex|sub(tree)}
<setstyle>={exact|expand}
<modifier>={expand}
<name>=aci		<pattern>=<attrname>]

این موارد ممکن است به‌صورت ترکیبی مشخص شوند.

نویسه عام (wildcard) * به همه اشاره دارد.

کلیدواژه‌های دارای پیشوند real مانند همتاهای بدون پیشوند خود عمل می‌کنند؛ با این تفاوت که بررسی به ترتیب با DN احراز هویت و DN مجوزدهی انجام می‌گیرد.

کلیدواژه anonymous بدین معناست که دسترسی به کلاینت‌های احراز هویت‌نشده اعطا می‌شود؛ این کلیدواژه بیشتر برای محدود کردن دسترسی کلاینت‌های احراز هویت‌نشده به منابع احراز هویت (مانند مشخصه userPassword) جهت اهداف احراز هویت به کار می‌رود.

کلیدواژه users بدین معناست که دسترسی به کلاینت‌های احراز هویت‌شده اعطا می‌شود.

کلیدواژه self بدین معناست که دسترسی به یک مدخل برای خود همان مدخل مجاز است (برای مثال، مدخلی که مورد دسترسی قرار می‌گیرد و مدخل درخواست‌کننده باید یکسان باشند). این کلیدواژه امکان استفاده از شیوه level{<n>} را فراهم می‌کند، که در آن <n> مشخص می‌کند کدام نیا (ancestor) از DN باید در تطابق‌ها استفاده شود. یک مقدار مثبت نشان می‌دهد که <n>-امین نیای DN کاربر باید در نظر گرفته شود؛ یک مقدار منفی نشان می‌دهد که <n>-امین نیای هدف باید در نظر گرفته شود. برای مثال، یک عبارت "by self.level{1} ..." زمانی تطابق می‌یابد که شیء "dc=example,dc=com" توسط "cn=User,dc=example,dc=com" مورد دسترسی قرار گیرد. یک عبارت "by self.level{-1} ..." زمانی تطابق می‌یابد که همان کاربر به شیء "ou=Address Book,cn=User,dc=example,dc=com" دسترسی پیدا کند.

دستور dn=<DN> بدین معناست که دسترسی به DN منطبق اعطا می‌شود. توصیف‌کننده اختیاری شیوه dnstyle همان گزینه‌های فرم dn در فیلد <what> را ارائه می‌دهد. علاوه بر این، شیوه regex می‌تواند از جایگزینی زیررشته حاصل از زیرتطابق‌ها در عبارت dn.regex مربوط به <what> با استفاده از فرم $<digit>، که در آن digit عددی در بازه 0 تا 9 است (که در آن 0 با کل رشته تطابق دارد)، یا فرم ${<digit>+}، برای زیرتطابق‌های بزرگ‌تر از 9 بهره ببرد. جایگزینی زیررشته از مقدار مشخصه می‌تواند با استفاده از فرم ${v<digit>+} انجام شود. از آنجا که نویسه دلار برای نشان دادن جایگزینی زیررشته به کار می‌رود، نویسه دلاری که برای نشان دادن تطابق تا انتهای رشته استفاده می‌شود باید با یک نویسه دلار دوم گریز داده شود (escape شود)، مانند:

access to dn.regex="^(.+,)?uid=([^,]+),dc=[^,]+,dc=com$"
    by dn.regex="^uid=$2,dc=[^,]+,dc=com$$" write

توصیف‌کننده شیوه امکان داشتن یک modifier اختیاری را فراهم می‌کند. در حال حاضر، تنها نوع مجاز expand است، که باعث می‌شود جایگزینی زیررشته حاصل از زیرتطابق‌ها حتی زمانی که dnstyle از نوع regex نیست رخ دهد. توجه داشته باشید که dnstyle از نوع regex در مثال بالا تنها در صورتی ممکن است مفید باشد که عبارت <by> نیاز داشته باشد یک regex باشد؛ در غیر این صورت، اگر مقدار بخش دوم (از سمت راست) dc= از DN در مثال بالا ثابت بود، فرم

access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
    by dn.exact,expand="uid=$2,dc=example,dc=com" write

می‌توانست استفاده شود؛ و اگر لازم بود با مقدار موجود در عبارت <what> تطابق یابد، فرم

access to dn.regex="^(.+,)?uid=([^,]+),dc=([^,]+),dc=com$"
    by dn.exact,expand="uid=$2,dc=$3,dc=com" write

می‌توانست به کار رود.

فرم‌های دیگری از عبارت <what> به‌جز regex نیز می‌توانند زیرتطابق‌ها را ارائه دهند. فرم‌های base(object)، sub(tree)، one(level) و children مقدار $0 را به‌عنوان تطابق کل رشته ارائه می‌دهند. فرم‌های sub(tree)، one(level) و children همچنین $1 را به‌عنوان تطابق راست‌ترین بخش DN همان‌طور که در عبارت <what> تعریف شده، ارائه می‌کنند. این قابلیت ممکن است به‌عنوان مثال برای اعطای دسترسی به تمامی نیاکان یک کاربر با تعریف زیر مفید باشد:

access to dn.subtree="dc=com"
    by dn.subtree,expand="$1" read

که بدین معناست تنها دسترسی به مدخل‌هایی که در DN عبارت <by> ظاهر می‌شوند مجاز است.

فرم level{<n>} یک توسعه و تعمیم از فرم onelevel است که با تمام DNهایی که <n>-امین نیاکان آن‌ها الگو است تطابق می‌یابد. بنابراین، level{1} معادل با onelevel و level{0} معادل با base است.

اعطای هرگونه امتیاز دسترسی به DNای که دقیقاً با rootdn پایگاه‌داده‌ای که ACLها برای آن اعمال می‌شوند تطابق دارد کاملاً بی‌فایده است، زیرا این DN به‌طور ضمنی دارای امتیاز نوشتن برای کل درخت آن پایگاه‌داده است. در واقع، کنترل دسترسی برای rootdn دور زده می‌شود (bypassed) تا مسئله ذاتی «مرغ و تخم‌مرغ» حل شود.

دستور dnattr=<attrname> بدین معناست که دسترسی به درخواست‌هایی اعطا می‌شود که DN آن‌ها در مشخصه <attrname> از مدخلی که به آن دسترسی پیدا می‌شود فهرست شده باشد.

دستور group=<group> بدین معناست که دسترسی به درخواست‌هایی اعطا می‌شود که DN آن‌ها در مدخل گروهی که DN آن توسط <group> مشخص شده است، فهرست شده باشد. پارامترهای اختیاری <objectclass> و <attrname> کلاس شیء (objectClass) و نوع مشخصه (attributeType) عضو مربوط به مدخل گروه را تعیین می‌کنند. مقادیر پیش‌فرض به ترتیب groupOfNames و member هستند. توصیف‌کننده اختیاری شیوه <style> می‌تواند expand باشد، به این معنی که <group> به‌عنوان یک رشته جایگزین (اما نه به‌عنوان یک عبارت باقاعده) طبق regex(7) و/یا re_format(7) بسط می‌یابد، و exact، به این معنی که تطابق دقیق استفاده خواهد شد. اگر شیوه بخش DN در عبارت <what> از نوع regex باشد، زیرتطابق‌ها طبق regex(7) و/یا re_format(7) در دسترس قرار می‌گیرند؛ سایر شیوه‌ها زیرتطابق‌های محدودی را مطابق آنچه در بالا درباره فرم DN از عبارت <by> بحث شد ارائه می‌دهند.

برای گروه‌های ایستا (static groups)، نوع مشخصه تعیین‌شده باید دارای نحو DistinguishedName یا NameAndOptionalUID باشد. برای گروه‌های پویا (dynamic groups) نوع مشخصه باید یک زیرنوع از نوع مشخصه labeledURI باشد. تنها URIهای LDAP به فرم ldap:///<base>??<scope>?<filter> تنها از طریق جستجو در سرور محلی، در یک گروه پویا ارزیابی خواهند شد.

دستورات peername=<peername>، sockname=<sockname>، domain=<domain> و sockurl=<sockurl> بدین معنا هستند که IP میزبان متصل‌شونده (به فرم IP=<ip>:<port> برای IPv4، یا IP=[<ipv6>]:<port> برای IPv6) یا نام فایل لوله نام‌گذاری‌شده (named pipe) میزبان متصل‌شونده (به فرم PATH=<path> در صورت اتصال از طریق یک لوله نام‌گذاری‌شده) برای peername، نام فایل لوله نام‌گذاری‌شده برای sockname، نام میزبان متصل‌شونده برای domain و URL متصل‌شونده برای sockurl جهت تعیین دسترسی با pattern مقایسه می‌شوند. همان قوانین style برای تطابق الگو که برای حالت group شرح داده شد اعمال می‌شوند، به‌علاوه شیوه regex که به معنای expand زیرتطابق و تطابق regex پارامترهای اتصال مربوطه است. شیوه exact در عبارت <peername> (حالت پیش‌فرض) مستلزم تطابق دقیق با حساسیت به بزرگی و کوچکی حروف روی IP کلاینت، شامل پیشوند IP= و :<port> پایانی، یا path کلاینت، شامل پیشوند PATH= در صورت اتصال از طریق لوله نام‌گذاری‌شده است. شیوه ویژه ip الگو را به‌صورت <peername>=<ip>[%<mask>][{<n>}] تفسیر می‌کند، که در آن <ip> و <mask> نمایش رقمی نقطه‌دار از IP و ماسک هستند، در حالی که <n>، محصور در پرانتزهای شکسته، یک درگاه اختیاری است. همین موضوع برای آدرس‌های IPv6 در هنگام استفاده از شیوه ویژه ipv6 نیز صدق می‌کند. هنگام بررسی امتیازات دسترسی، بخش IP از peername استخراج شده، پیشوند IP= و بخش :<port> حذف می‌گردند، و پس از اعمال ماسک با <mask>، با بخش <ip> از الگو مقایسه می‌شود: ((peername & <mask>) == <ip>). به‌عنوان مثال، peername.ip=127.0.0.1 و peername.ipv6=::1 تنها اتصالات از localhost را مجاز می‌دانند، peername.ip=192.168.1.0%255.255.255.0 اتصالات از هر IP در دامنه کلاس C با نشانی 192.168.1 را مجاز می‌کند، و peername.ip=192.168.1.16%255.255.255.240{9009} تنها در صورتی که درگاه 9009 استفاده شود، اتصالات از هر IP در محدوده 192.168.1.[16-31] از همان دامنه را مجاز می‌سازد. شیوه ویژه path هنگام اتصال از طریق یک لوله نام‌گذاری‌شده، پیشوند PATH= را از peername حذف کرده و یک تطابق دقیق روی الگوی داده‌شده انجام می‌دهد. عبارت <domain> همچنین شیوه subtree را مجاز می‌داند، که زمانی موفق می‌شود که یک نام کاملاً واجد شرایط (FQDN) دقیقاً با الگوی domain تطابق یابد، یا بخش انتهایی آن، پس از یک نقطه، دقیقاً با الگوی domain مطابقت داشته باشد. شیوه expand مجاز است، که متضمن تطابق exact همراه با بسط زیرتطابق است؛ استفاده از expand به‌عنوان یک اصلاح‌کننده شیوه مناسب‌تر در نظر گرفته می‌شود. به‌عنوان مثال، domain.subtree=example.com با www.example.com تطابق می‌یابد، اما با www.anotherexample.com تطابق نخواهد یافت. مقدار domain میزبان متصل‌شونده با انجام جستجوی معکوس DNS تعیین می‌شود. از آنجا که این جستجو به‌راحتی می‌تواند جعل (spoof) شود، استفاده از دستور domain اکیداً منع می‌شود. به‌طور پیش‌فرض، جستجوهای معکوس غیرفعال هستند. توصیف‌کننده اختیاری domainstyle در عبارت <domain> گزینه modifier را مجاز می‌داند؛ تنها مقداری که در حال حاضر پشتیبانی می‌شود expand است که باعث می‌شود جایگزینی زیررشته حاصل از زیرتطابق‌ها حتی زمانی که domainstyle از نوع regex نیست صورت گیرد، بسیار شبیه به کاربرد متناظر در عبارت <dn>.

دستور set=<pattern> هنوز مستندسازی نشده است.

دستور dynacl/<name>[/<options>][.<dynstyle>][=<pattern>] بدین معناست که بررسی دسترسی به روش تعریف‌شده توسط مدیر که توسط <name> مشخص شده واگذار می‌شود، که می‌تواند در زمان اجرا با استفاده از دستور moduleload ثبت گردد. فیلدهای <options>، <dynstyle> و <pattern> اختیاری هستند و مستقیماً به روال تجزیه ثبت‌شده ارسال می‌شوند. قابلیت Dynacl آزمایشی است؛ و باید در زمان کامپایل فعال شود.

دستور dynacl/aci[=<attrname>] بدین معناست که کنترل دسترسی توسط مقادیر موجود در attrname از خود مدخل تعیین می‌شود. مقدار اختیاری <attrname> مشخص می‌کند کدام نوع مشخصه (attributeType) اطلاعات ACI را در مدخل نگهداری می‌کند. به‌طور پیش‌فرض، مشخصه عملیاتی OpenLDAPaci استفاده می‌شود. قابلیت ACIها آزمایشی است؛ و باید در زمان کامپایل فعال شود.

دستورات ssf=<n>، transport_ssf=<n>، tls_ssf=<n> و sasl_ssf=<n> حداقل ضریب استحکام امنیتی (Security Strength Factor یا ssf) مورد نیاز برای اعطای دسترسی را تعیین می‌کنند. این مقدار باید یک عدد صحیح مثبت باشد.

بخش <ACCESS> (THE <ACCESS> FIELD)

فیلد اختیاری <access> ::= [[real]self]{<level>|<priv>} سطح دسترسی یا امتیازات دسترسی خاصی را تعیین می‌کند که فیلد who خواهد داشت. اجزای آن به صورت زیر تعریف می‌شوند:

<level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage
<priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+

تعدیل‌کننده self عملیات خاصی مانند داشتن یک سطح دسترسی یا امتیاز خاص را فقط در صورتی مجاز می‌سازد که عملیات شامل نام کاربری باشد که درخواست دسترسی داده است. این امر دلالت بر مجاز بودن (authorized) کاربری دارد که درخواست دسترسی می‌کند. تعدیل‌کننده realself به DN احراز هویت‌شده (authenticated DN) در مقابل DN مجازِ (authorized DN) تعدیل‌کننده self اشاره دارد. یک مثال، دسترسی selfwrite به ویژگی member در یک گروه است، که به فرد اجازه می‌دهد DN خود را به فهرست اعضای یک گروه اضافه یا از آن حذف کند، در حالی که مجاز به تأثیرگذاری روی سایر اعضا نیست.

مدل دسترسی level بر تفسیر افزایشی امتیازات دسترسی تکیه دارد. سطوح ممکن عبارتند از: none، disclose، auth، compare، search، read، write، و manage. هر سطح دسترسی شامل تمام سطوح ماقبل خود نیز می‌شود؛ بنابراین manage تمام دسترسی‌ها از جمله دسترسی مدیریتی را اعطا می‌کند. این دسترسی برخی تغییرات را مجاز می‌کند که در غیر این صورت توسط مدل داده LDAP یا طرح‌واره (schema) دایرکتوری ممنوع می‌بود، به عنوان مثال تغییر objectclass ساختاری یک مدخل، یا تغییر یک ویژگی عملیاتی که به صورت غیرقابل تغییر توسط کاربر تعریف شده است. دسترسی write در واقع ترکیبی از add و delete است، که به ترتیب امتیاز نوشتن را به افزودن یا حذف <what> مشخص‌شده محدود می‌کنند.

سطح دسترسی none هرگونه دسترسی، از جمله افشا در صورت بروز خطا (disclosure on error) را غیرمجاز می‌کند.

سطح دسترسی disclose اجازه افشای اطلاعات در هنگام بروز خطا را می‌دهد.

سطح دسترسی auth بدین معنی است که فرد صرفاً برای انجام عملیات احراز هویت/مجوزدهی (مانند bind) مجاز به دسترسی به یک ویژگی است، بدون هیچ دسترسی دیگری. این مورد برای اعطای کمترین سطح دسترسی ممکن به کلاینت‌های احراز هویت‌نشده به منابع حیاتی، مانند گذرواژه‌ها، مفید است.

مدل دسترسی priv بر تنظیم صریح امتیازات دسترسی برای هر بند تکیه دارد. علامت = دسترسی‌های از پیش تعریف‌شده را بازنشانی می‌کند؛ در نتیجه، امتیازات دسترسی نهایی تنها مواردی خواهد بود که توسط این بند تعیین شده است. علامت‌های + و - امتیازات دسترسی را به موارد موجود اضافه کرده یا از آن‌ها کم می‌کنند. امتیازات عبارتند از: m برای manage، w برای write، a برای add، z برای delete، r برای read، s برای search، c برای compare، x برای authentication، و d برای disclose. بیش از یکی از امتیازات فوق را می‌توان در یک عبارت اضافه کرد. 0 نشان‌دهنده عدم وجود هیچ امتیازی است و فقط به تنهایی استفاده می‌شود (مثلاً +0). توجه داشته باشید که +az معادل +w است.

اگر هیچ دسترسی داده نشود، به طور پیش‌فرض +0 خواهد بود.

بخش <CONTROL> (THE <CONTROL> FIELD)

فیلد اختیاری <control> جریان اعمال قواعد دسترسی را کنترل می‌کند. می‌تواند دارای یکی از اشکال زیر باشد:

stop
continue
break

که در آن stop، حالت پیش‌فرض، به این معنی است که در صورت تطابق، بررسی دسترسی متوقف می‌شود. دو شکل دیگر برای ادامه پردازش بندهای دسترسی استفاده می‌شوند. به طور دقیق‌تر، شکل continue امکان بررسی سایر بندهای <who> را در همان بند <access> فراهم می‌سازد، به طوری که ممکن است به تغییر تدریجی امتیازات منجر شوند، در حالی که شکل break امکان پردازش سایر بندهای <access> که با همان هدف تطابق دارند را می‌دهد. این مثال (ساده‌لوحانه) را در نظر بگیرید:

access to dn.subtree="dc=example,dc=com" attrs=cn
	by * =cs break
access to dn.subtree="ou=People,dc=example,dc=com"
	by * +r

که به همه افراد زیر درخت "dc=example,dc=com" امتیازات search و compare را می‌دهد، در حالی که قاعده دوم دسترسی read را نیز در زیردرخت "ou=People" مجاز می‌کند، یا این مثال (حتی ساده‌لوحانه‌تر):

access to dn.subtree="dc=example,dc=com" attrs=cn
	by * =cs continue
	by users +r

که به همه امتیازات search و compare را اعطا کرده و امتیازات read را به کلاینت‌های احراز هویت‌شده اضافه می‌کند.

یک کاربرد مفید، اعطای آسان امتیازات write به یک updatedn است که با rootdn تفاوت دارد. در این حالت، از آنجا که updatedn به (تقریباً) همه داده‌ها دسترسی write نیاز دارد، می‌توان از

access to *
	by dn.exact="cn=The Update DN,dc=example,dc=com" write
	by * break

به عنوان اولین قاعده دسترسی استفاده کرد. در نتیجه، مگر اینکه عملیات با هویت updatedn انجام شود، کنترل مستقیماً به قواعد بعدی واگذار می‌شود.

نیازمندی‌های عملیات (OPERATION REQUIREMENTS)

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

عملیات add نیازمند امتیازات add (=a) بر روی شبه‌ویژگی entry از مدخلی است که اضافه می‌شود، و امتیازات add (=a) بر روی شبه‌ویژگی children از والد مدخل. هنگام اضافه کردن مدخل پسوند (suffix entry) یک پایگاه داده، دسترسی add به children از DN خالی ("") مورد نیاز است. همچنین اگر بررسی ACL محتوای Add روی پایگاه داده پیکربندی شده باشد (صفحه راهنمای slapd.conf(5) یا slapd-config(5) را ببینید)، add (=a) بر روی تمامی ویژگی‌هایی که اضافه می‌شوند مورد نیاز خواهد بود.

عملیات bind هنگامی که اعتبارنامه‌ها در دایرکتوری ذخیره شده‌اند، نیازمند امتیازات auth (=x) بر روی ویژگی که اعتبارنامه‌ها در آن ذخیره شده‌اند (معمولاً userPassword) است.

عملیات compare به امتیازات compare (=c) بر روی ویژگی مورد مقایسه نیاز دارد.

عملیات delete نیازمند امتیازات delete (=z) بر روی شبه‌ویژگی entry از مدخل در حال حذف، و امتیازات delete (=d) بر روی شبه‌ویژگی children از والد مدخل است.

عملیات modify نیازمند امتیازات write (=w) بر روی ویژگی‌های در حال تغییر است. به طور مشخص، add (=a) برای افزودن مقادیر جدید، delete (=z) برای حذف مقادیر موجود، و هر دو مورد delete و add (=az)، یا write (=w)، برای جایگزینی مقادیر موجود مورد نیاز هستند.

عملیات modrdn نیازمند امتیازات write (=w) بر روی شبه‌ویژگی entry از مدخلی است که DN نسبی آن در حال تغییر است، امتیازات delete (=z) بر روی شبه‌ویژگی children از والدین مدخل قدیمی، امتیازات add (=a) بر روی شبه‌ویژگی children از والدین مدخل جدید، و امتیازات add (=a) بر روی ویژگی‌هایی که در DN نسبی جدید وجود دارند. همچنین در صورتی که deleteoldrdn بر روی 1 تنظیم شده باشد، امتیازات Delete (=z) بر روی ویژگی‌های موجود در DN نسبی قدیمی مورد نیاز خواهد بود.

عملیات search نیازمند امتیازات search (=s) بر روی شبه‌ویژگی entry از searchBase است (نکته: این مورد با OpenLDAP 2.4 معرفی شد). سپس، برای هر مدخل، به امتیازات search (=s) بر روی ویژگی‌هایی که در فیلتر تعریف شده‌اند نیاز دارد. مدخل‌های حاصل در نهایت برای امتیازات read (=r) بر روی شبه‌ویژگی entry (برای دسترسی خواندن به خود مدخل) و برای دسترسی read (=r) بر روی هر مقدار از هر ویژگی که درخواست شده است، بررسی می‌شوند. همچنین، برای هر شیء referral که در ایجاد ارجاعات ادامه‌دار (continuation references) استفاده می‌شود، عملیات نیازمند دسترسی read (=r) بر روی شبه‌ویژگی entry (برای دسترسی خواندن به خود شیء referral)، و همچنین دسترسی read (=r) به ویژگی نگهدارنده اطلاعات ارجاع (معمولاً ویژگی ref) است.

برخی عملیات داخلی و برخی controls نیازمند امتیازات دسترسی خاصی هستند.

نگاشت SASL authzID و کنترل LDAP proxyAuthz نیازمند امتیازات auth (=x) بر روی تمامی ویژگی‌هایی هستند که در فیلتر جستجوی نگاشت‌های regexp در URI (سمت راست دستورهای authz-regexp) وجود دارند. همچنین امتیازات Auth (=x) بر روی ویژگی authzTo از هویت اجازه‌دهنده (authorizing identity) و/یا بر روی ویژگی authzFrom از هویت مجازشده (authorized identity) مورد نیاز است. در هر دو حالت، این هویت اجازه‌دهنده است که نیازمند امتیازات است (یعنی هویتی که احراز هویت شده و اکنون سعی دارد با استفاده از مجوزهای موجودیتی دیگر عملیاتی انجام دهد).

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

کنترل دسترسی برای جستجوی مدخل‌ها توسط frontend بررسی می‌شود، بنابراین توسط تمامی بک‌اندها به طور کامل رعایت می‌گردد؛ برای تمامی عملیات دیگر و برای مرحله کشف در عملیات جستجو، معناشناسی کامل ACL تنها توسط بک‌اندهای اصلی، یعنی slapd-mdb(5) پشتیبانی می‌شود.

برخی بک‌اندهای دیگر، مانند slapd-sql(5)، ممکن است به طور کامل از آن‌ها پشتیبانی کنند؛ سایر بک‌اندها ممکن است تنها بخشی از معناشناسی توصیف‌شده را پشتیبانی کنند، یا حتی در برخی جنبه‌ها تفاوت داشته باشند. جزئیات مرتبط در صفحات راهنمای اختصاصی هر بک‌اند شرح داده شده است.

هشدارها (CAVEATS)

اکیداً توصیه می‌شود که مناسب‌ترین <dnstyle> را به طور صریح در بندهای <what> و <who> به کار ببرید، تا از مشخص‌سازی‌های احتمالاً نادرست قوانین دسترسی و همچنین به دلایل کارایی (اجتناب از تطبیق غیرضروری regex در صورتی که یک تطابق دقیق کفایت می‌کند) جلوگیری شود.

یک مدیر ممکن است قاعده‌ای به این شکل ایجاد کند:

access to dn.regex="dc=example,dc=com"
	by ...

با این انتظار که با تمام مدخل‌ها در زیردرخت "dc=example,dc=com" تطابق یابد. اما این قاعده در واقع با هر DN که در هر جای خود شامل زیررشته "dc=example,dc=com" باشد تطبیق می‌یابد. به این معنی که قاعده با هر دو مورد "uid=joe,dc=example,dc=com" و "dc=example,dc=com,uid=joe" مطابقت دارد.

برای تطبیق زیردرخت مورد نظر، قاعده باید با دقت بیشتری نوشته شود:

access to dn.regex="^(.+,)?dc=example,dc=com$"
	by ...

به دلایل کارایی، بهتر است از سبک subtree استفاده شود.

access to dn.subtree="dc=example,dc=com"
	by ...

هنگام نوشتن قواعد زیرتطابق (submatch)، ممکن است اجتناب از استفاده غیرضروری از <dnstyle> نوع regex مفید باشد؛ برای نمونه، جهت اعطای دسترسی به زیردرخت کاربری که با بند <what> تطابق دارد، می‌توان از مورد زیر استفاده کرد:

access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
	by dn.regex="^uid=$2,dc=example,dc=com$$" write
	by ...

با این حال، از آنجا که تمام آنچه در بند <by> مورد نیاز است انبساط زیررشته است، یک راه‌حل کارآمدتر عبارت است از:

access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
	by dn.exact,expand="uid=$2,dc=example,dc=com" write
	by ...

در واقع، در حالی که مقدار regex برای <dnstyle> به معنای انبساط زیررشته است، exact، و همچنین تمام مقادیر دیگر <dnstyle> مختص DN چنین نیستند، بنابراین باید صراحتاً درخواست شود.

فایل‌ها (FILES)

/etc/openldap/slapd.conf

فایل پیکربندی پیش‌فرض slapd

همچنین ببینید (SEE ALSO)

slapd(8), slapd-*(5), slapacl(8), regex(7), re_format(7)

"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin)

قدردانی‌ها (ACKNOWLEDGEMENTS)

نرم‌افزار OpenLDAP توسط پروژه OpenLDAP در http://www.openldap.org توسعه یافته و نگهداری می‌شود. نرم‌افزار OpenLDAP از انتشار LDAP 3.3 دانشگاه میشیگان برگرفته شده است.