پرچمداران

در این قسمت میخوایم تلاش کنیم کودا (cuda) رو بر روی اوبونتو (Ubuntu) نصب کنیم نسخه کودا که نصب کردم ۱۰.۰ هست و همچنین اوبونتو ۱۸.۰۴ ولی بعید میدونم فرق خاصی داشته باشه نصب بقیه ورژن های چه کودا چه اوبونتو. اول از همه به قسمت Software & Updates برید و پنجره Additional Drivers رو انتخاب کنید و کارت گرافیک خودتون رو نصب کنید بعد از اینکه نصب شد سیستم رو ریبوت کنید یا در ترمینال خط زیر و بزنید: sudo reboot در مرحله بعد باید ملزومات کودا رو نصب کنید و از اونجایی که وقتی فایل deb رو نصب کنید این وابستگی ها خودشون نصب می‌شن ماهم دستی خودمون نصب می‌کنیم چون از deb استفاده نمی‌کنیم! پس: sudo apt-get install freeglut3 freeglut3-dev libxi-dev libxmu-dev این خط پکیج های لازم رو برای کتابخانه های GL - GLU - Xi - Xmu و چندین تای دیگه رو میگیره که بعدا به عنوان وابستگی نصب میشن. حالا به سایت Cuda Zone و دانلود رو بزنید بعدش تو صفحه باز شده Architecture و Distribution و Version روخودتون بر اساس لینوکسی که دارید پیش ببرید و برای دریافت اطلاعات در اوبونتو میتونید از lsb_release -a استفاده کنید. در قسمت نوع نصاب‌ (installer type) گزینه runfile (local) رو انتخاب کنید و دوتا فایل رو که یکی در حد چندین مگابایت و دیگری چیزی در حدود ۲ گیگابایت هست رو دانلود کنید. حالا نوبت نصب cuda-toolkit و نمونه ها (samples): sudo sh cuda_10.0.130_410.48_linux.run اینو که زدید بعدش سوالاتی مثل سوالات زیر پرسیده میشه ازتون و دقت کنید مثل نه دقیقا برای همین سوالات و بخونید و ببینید کدوم پرسیده میشه و کدوم پرسیده نمیشه البته اگر کودا ۱۰ نصب می‌کنید دقیقا همین سوالا پرسیده میشه یا اینکه خود شرکت عوض کرده خلاصه دقت کنید تا در زندگی پیشرفت کنید!! Install NVIDIA Accelerated Graphics Driver for Linux-x86_64 396.26? (y)es/(n)o/(q)uit: n Install the CUDA 10.0 Toolkit? (y)es/(n)o/(q)uit: y Enter Toolkit Location [ default is /usr/local/cuda-10.0 ]: Do you want to install a symbolic link at /usr/local/cuda? (y)es/(n)o/(q)uit: y Install the CUDA 10.0 Samples? (y)es/(n)o/(q)uit: y Enter CUDA Samples Location [ default is /home/kinghorn ]: /usr/local/cuda-10.0 برای بعضی ها شاید سوال: You are attempting to install on an unsupported configuration. Do you wish to continue? (y)es/(n)o [ default is no ]: y هم پرسیده بشه که جوابش و y بدید که بگذرید. سوال اول داره اجازه میگیره که درایور کارت گرافیک رو نصب کنه: از اونجایی که بالا ما نصبش کردیم حتما حتما حتما بزنید n و تقریبا مهمترین قسمت این نصب هم همینه که اینو بزنید n. سوال دوم داره اجازه نسخه کودا تولکیت (cuda toolkit) رو ازتون میگیره که این برمیگرده به نسخه ای که دانلود کردید و برای مثلا من نسخه ۱۰.۰ بود. سوال سوم مکان رو ازتون میخواد که شما همون پیش فرض رو بذارید یعنی دکمه Enter رو بزنید تا برسید به سوال چهارم. سوال چهارم هم اجازه برای نصب symbolic در مکانی که در سوال بالا بهش دادید و سوال پنجم هم نصب نمونه هاست و مکانش رو در سوال ششم بصورتی که نوشتم با این تفاوت که بجای فایل کودا فایل کودا نسخه خودتون و قرار بدید. Enter CUDA Samples Location [ default is /home/kinghorn ]: /usr/local/cuda-x.x بحای x.x نسخه خودتون رو بنویسید. بعضی اوقات خطاهایی بدلیل کارت گرافیک و اینا میاد که خودش چند خط بعد نوشته جلو کلمه try چه چیزی بزنید و اگر اون ارور هارو دریافت کردید اون خط رو بزنید و ان شالله نصب میشه بعد از این کارا اون فایل چند مگابایتی رو حالا اجرا کنید sudo sh cuda_10.0.130.1_linux.run اسمش هم دیگه به چیزی که دارید نصب میکنید بستگی داره و خلاصش اینه که فایلی که اسم کوتاه داره همون چند مگابایتیه هست و اون فایل که اسم بلندی داره ۲ گیگابایتیه هستش. حالا نوبت مقدار دهی Environment Variables: در اینجا مقدار Environment هارو با این فرض مقدار دهی میکنیم که چندین کاربر (user) داریم. البته سیستم خود من تک کاربره هست ولی همچنان با این متد رفتم شما هم میتونید برید و مشکلی نداره sudo nano /etc/profile.d/cuda.sh با این خط به فایل در مسیر داده شده به اسم cuda.sh می‌سازیم و بعد از اون با دستور nano باز میکنیم و متن رو داخلش قرار میدیم: export PATH=$PATH:/usr/local/cuda/bin export CUDADIR=/usr/local/cuda بعد از اون فایل رو ذخیره می‌کنیم یعنی کلید ها Ctrl + x سپس ‌y و بعد از اون Enter رو میزنیم و ذخیره میشه فایل بعد از این خط زیر و اجرا میکنیم تا فایل مورد نظر باز بشه sudo nano /etc/ld.so.conf.d/cuda.conf حالا خط زیر و انتقال میدیم داخلش و بعد همون دکمه های قبلی رو میزنیم تا فایل ذخیره بشه /usr/local/cuda/lib64 بعد از این کار دستور زیر و اجرا میکنیم و بعد از دستور زیر یه بار log out می‌کنیم تا محتویات اجرا شن و بعدش دیگه دسترسی دارید از شل (shell) برای استفاده از دستور ها رو دارید sudo ldconfig حالا اگر این و انجام دادید که خوشا به سعادتتون و خسته نباشید اگرم منتظرید که تک کاربرشو بگم بفرما: یه فایل بنام cudax.x-env می‌سازید که اون x.x ورژن کودا شماست مثلا sudo nano cuda10.0-env بعدشم سه خط و زیر و بهش اضافه می‌کنیم و با همون دکمه های قبلی ذخیرش می‌کنیم export PATH=$PATH:/usr/local/cuda-10.0/bin export CUDADIR=/usr/local/cuda-10.0 export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/cuda-10.0/lib64 تو این سه خط میبینید نسخه کودا هم اضاف کردم در صورتی که میتونستم فقط کودا رو بنویسیم ولی اینطوری شما میتونید چندین ورژن کودا نصب کنید و هرکدوم Environment Variables خودشو داشته باشه و حالا هر وقت خواستید به سادگی با دستور source cuda-10.0-env حالا با دستور مقدار Environmentها رو قرار میدیم یا به قول معروف set می‌کنیم. البته همچنین فایل رو میتونید هرجایی که خواستید بذارید ولی یادتون باشه که مسیرش رو اگر تغییر دادید موقع زدن خط بالا ادرس رو به source بدید. تموم! به همین راحتی کودا رو نصب کردید ( البته امیدوارم! ) با دستور nvcc --version ورژن کودا نصب شده بهتون نمایش داده می‌شه و با دستور nvidia-smi هم اطلاعات کارت گرافیتون. حالا میخوام یه نمونه کد تست کنیم که جمع دو ماتریس هست: اول با ترمینال و بعدش با vscode انجام میدیم, در ترمینال یه فایل می‌سازیم با پسوند .cu یعنیsudo nano firstcuda.cu و بعدش وقتی باز شد خطوط پایین رو داخلش قرار میدیم #include "cuda_runtime.h" #include "device_launch_parameters.h" #include <stdio.h> __global__ void addKernel(int *c, const int *a, const int *b){ int i = threadIdx.x; c[i] = a[i] + b[i]; } int main(){ const int arraySize = 5; const int a[arraySize] = { 1, 2, 3, 4, 5 }; const int b[arraySize] = { 10, 20, 30, 40, 50 }; int c[arraySize] = { 0 }; cudaError_t cudaStatus; int *dev_a = 0, *dev_b = 0, *dev_c = 0; cudaMalloc((void**)&dev_c, arraySize * sizeof(int)); cudaMalloc((void**)&dev_a, arraySize * sizeof(int)); cudaMalloc((void**)&dev_b, arraySize * sizeof(int)); cudaMemcpy(dev_a, a, arraySize * sizeof(int), cudaMemcpyHostToDevice); cudaMemcpy(dev_b, b, arraySize * sizeof(int), cudaMemcpyHostToDevice); addKernel << <1, arraySize >> >(dev_c, dev_a, dev_b); cudaDeviceSynchronize(); cudaMemcpy(c, dev_c, arraySize * sizeof(int), cudaMemcpyDeviceToHost); printf("{1,2,3,4,5} + {10,20,30,40,50} = {%d,%d,%d,%d,%d}\n", c[0], c[1], c[2], c[3], c[4]); cudaStatus = cudaGetLastError();if (cudaStatus != cudaSuccess)printf("cudaDeviceReset failed!"); return 0; } بعد ذخیره کنید و دستور nvcc firstcuda.cu -o firstcuda رو بزنید. این دستور یعنی با کامپیالر nvcc برنامه firstcuda.cu رو کامپایل کن و خروجی -o بنام firstcuda بده. که خروجی در همون پوشه هست که هموطوری که میدونید بطور پیش فرض همه این ها در قسمت home هستند. حالا خروجی رو اجرا کنید یعنی ./firstcuda و این دستور خروجی رو اجرا میکنه و به شما نمایش میده. خروجی که باید نمایش داده بشه {1,2,3,4,5} + {10,20,30,40,50} = {11,22,33,44,55} حالا بریم سراغ vscode که یکم بیشتر ولی رنگی تره, بقول معروف هرچی رنگین تر باشی سخت تر بدست میای! از قسمت ترمینال (Terminal) گزینه New Terminal رو انتخاب کنید و بعد بنویسید touch test.cu که با این دستور شما فایل test.cu رو میسازید.حالا کد هارو داخلش قرار بدید بعدش میتونید از داخل ترمینال داخل vscode بقیه مراحل و مثل قبل برید و کامپیال کنید و بعدشم اجرا کنید فایل خروجی رو ولی راه قشنگ تر اینه که از قسمت ترمینال گزینه Configure Default Build Task رو انتخاب کنید بعد از اون یه پنجرکی (پنجره کوچک!) باز میشه که روی Create tasks.json file from template کلیک کنید و بعدشم گزینه Others. حالا در فایل جدیدی که ساخته شده با پسوند .json باید خط های زیر رو قرار بدید { "version": "2.0.0", "tasks": [ { "label": "build", "type": "shell", "command": "nvcc", "args": [ "test.cu", "-o", "${workspaceFolderBasename}" ] } ] } خب حالا باید درستش کنیم: اولین چیز لیبل (label) هست که نشون دهنده اسم task میشه و بعد از اون نوع که باید شل (shell) باشه و مهم تر از همه command که نشون دهنده کامپیالرمون هست باید nvcc باشه تا سیستم به طور خودکار کتابخانه هایی که استفاده شده در کد رو تشخیص بده. ارگومان ها اول اسم برنامه هست و بعدی به معنای خروجی هست و سومی نام فایل خروجی که اونی که نوشته شده یعنی هم اسم فایلی که داخلشیم. بعد از سیو کردن (Ctrl + s) وقتی از قسمت ترمینال گزینه Run Task رو میزنیم build نمایش داده میشه و وقتی میزنیمش این کد کامپیایل میشه و در همون فولدر خروجی رو بهمون میده و اگرم دقت کنید یک فایل a.out هم براتون نمایش داده میشه در vscode. حالا کاری میکنیم که وقتی ساخته شد اجرا هم بشه و در ترمینال vscode نمایش داده بشه. اگر دقت کرده باشید خطی جدید به صورت "problemMatcher": [] اضافه شده برای همین در پایین که کل کد هست این خط هارو وارد نکنید: { "version": "2.0.0", "tasks": [ { "label": "build", "type": "shell", "command": "nvcc", "args": [ "test.cu", "-o", "${workspaceFolderBasename}" ], "problemMatcher": [] }, { "label": "run", "type": "shell", "command": "./${workspaceFolderBasename}", "dependsOn": [ "build" ] } ] } این قسمت جدیدی که اضافه شده داره میگه task با نام run اجرا کنه فایل رو (که در قسمت command برابر قرار داده شده این عمل) و باید حتما build اجرا شده باشه و به نوعی مثل همون شرط کار میکنه. اگر بخوایم اسمی خاص و همچنین در فولدر بندی خاصی این عملیات انجام بشه باید آدرس هارو بهشون بدیم: یعنی اول باید به مقدار آرگومان ورودی سوم قسمت build باید آدرس رو کامل وارد کنیم و همچنین در قسمت command بخش run هم همچین کاری کنیم به زبان ساده بخوام بگم میشه: ما یه فولدر بنام Practice داریم که تو اون فولدر فایل های مختلفی داریم که یه فولدر ساختیم بنام Cuda برای پروژه های کودا و همچنین یه فولدر در Cuda ساختیم به نام اسم پروژه ( فرض کنیم test.cu) پس آدرس فایل test.cu میشه ‌Practice/Cuda/Test/test.cu حالا اگر بخوایم اینو اجرا کنیم و خروجی رو ببینیم باید فایل .json رو اینطوری بنویسیم (دقت کنید به بزرگ و کوچیک بودن کلمات!): { "version": "2.0.0", "tasks": [ { "label": "build", "type": "shell", "command": "nvcc", "args": [ "Practice/Cuda/Test/test.cu", "-o", "Practice/Cuda/Test/test" ], "problemMatcher": [] }, { "label": "run", "type": "shell", "command": "./Practice/Cuda/Test/test", "dependsOn": [ "build" ], "problemMatcher": [] } ] } الان یه فایل ورودی با اون آدرس و با پسوند .cu به کامپایلر داده میشه و بعدش فایلی با نام test که نامی دلخواه هست و هرچی خواستید میتونید بذارید ساخته میشه به عنوان خروجی و در قسمت run میاد فایل رو با آدرس دقیقا در قسمت command میگیره و اجراش میکنه (دقیقا همون کاری که در ترمینال اوبونتو میکنید اینجا اومدید دکمه ایش کردید). حالا از قسمت Run Task روی run کلیک میکنیم تا کامپیال و هم چنین اجرا بشه. فایل نهایی شما (بعد از اجرا کردن) باید تقریبا به شکل زیر باشه (تقریبا برای این میگم شاید فردی بخواد وابستگی هارو بیشتر کنه و یا اسم برنامه چیز دیگه ای باشه و ...‌) { "version": "2.0.0", "tasks": [ { "label": "build", "type": "shell", "command": "nvcc", "args": [ "test.cu", "-o", "${workspaceFolderBasename}" ], "problemMatcher": [] }, { "label": "run", "type": "shell", "command": "./${workspaceFolderBasename}", "dependsOn": [ "build" ], "problemMatcher": [] } ] } خروجی زیبا رو در ترمینال میتونید تماشا کنید و لذت ببرید?خسته نباشید ان شالله همیشه پیروز و موفق باشید :] منبع اصلی هم مقاله Dr Donald Kinghorn و همچنین چندین (خیلی زیاد) ویدیو و مقاله و پاسخ جواب های دیگه تا تونستم بالاخره نصب کنم و بدون مشکل استفاده کنم.

Windows Access Control List (ACL) قسمت سوم (مفاهیم) مباحث مورد بررسی در این مقاله: Win32 Object Account Security Identifier (SID) Access Control Entries (AEC) Access Control List (ACL) Discretionary Access Control List (DACL) System Access Control List (SACL) Security Desctiptors (SD) Win32 Objects: سیستم عامل ویندوز قادر به ایجاد چندین نوع مختلف از اشیاء Win32 است. این اشیائ به گونه ای هستند که دارای حافظه می باشند. نمونه هایی از این اشیاء عبارتند از: Files Directories Registry keys Network shares Printer shares Semaphores Mutexes Process tokens و .... ماهیت این اشیاء به نوعی است که سیستم عامل می تواند آنها را در هر حافظه ای ذخیره کند (مانند رم، فلاپی، هارد دیسک، ذخیره در درایو شبکه، انتقال آن به دیگر کامپیوتر های روی شبکه). به عنوان مثال، فایل یک شئ از سیستم عامل می باشد. زمانی که شما یک فایل می سازید(مثلا یک فایل Microsoft word) سیستم عامل با آن به عنوان یک شئ برخورد می کند. حتی ممکن است بخواهید که فایل را داخل یک درایو ذخیره کنید تا بعدا به آن دسترسی داشته باشید. برای سیستم عامل مهم نیست که شما می خواهید شئ را در یک درایو ذخیره کنید یا نه، تنها این موضوع را می داند (اهمیت می دهد) که آن شئ مقداری از فضا را اشغال می کند (چه در رم یا جای دیگر). شئ پایدار (persistent object) شئی است که در دستگاه های حافظه بلند مدت ذخیره می شوند (مانند هارد دیسک) به گونه ای که داده ها بعدا قابل بازیابی باشند(ارساله داده به کارت صدا یا چاپگر باعث ایجاد شئ پایدار نمی شود، زیرا سیستم عامل بعدا قادر به بازیابی داده های آن نمی باشد). Win32 سیستم عامل به طور معمول در روز ده ها هزار شئ را مدیریت می کند. Win32 سیستم عامل تقریبا فقط یک مدیر اجرائی پیچیده به حساب می آید (object manager). از آنجایی که سیستم عامل با اشیاء در ارتباط است میداند که مواقعی وجود دارد که اشیائ باید ایمن شوند. مثلا زمان ذخیره یک پرونده حساس در یک هارد درایو، باید از کاربران غیر مجاز حفظ شود. Securing Objects: Win32، مکانیزمی را برای تامین امنیت انواع متفاوتی از اشیاء فراهم کرده است. به بیان ساده تر، تامین امنیت یک شئ به این معنی است که مجموعه ای از مجوز ها ایجاد شود که با شئ مورد نظر مرتبط باشد. هر شئ می تواند برای خو یک سری مجوز ها داشته باشد. Accounts: در قلب سیستم امنیتی Win32 همان چیزی است که به عنوان حساب کاربری (account) شناخته می شود. این همان چیزی است که فرد هنگام ورود به سیستم می تواند مشخص کند، و این به عنوان user account شناخته می شود. User account از یک نام شناسایی (Userid)، یک رمز عبور و یک دسته اطلاعات دیگر که فقط مربوط به آن کاربر خاص است، شامل می شود. انواع دیگری از حساب های کاربری وجود دارد. این حساب ها مانند حساب کاربری هستند به جز اینکه آنها کاربری را معرفی نمی کنند، بلکه انواع دیگری از حساب را معرفی می کنند. انواع حساب های کاربری عبارتند از: User accounts Machine accounts Domain accounts Group accounts حساب های user ،machine و domain همه دارای رمزعبور هستند. رمز ورود یک حساب کاربری به طور خودکار توسط Primary Domain Controller (PDC) و دستگاه مدیریت می شود. آخرین حساب، حساب group account می باشد. برخلاف حساب های دیگر، این حساب رمز عبور ندارد. دو نوع مختلف از حساب های گروهی وجود دارد: Local group و global group. تفاوت این دو فراتر از محدوده این مقاله می باشد، اما باید این را بدانید که حساب کاربریی وجود دارد که فاقد رمز عبور است. به طور معمول حساب های کاربری دارای نام هایی مانند زیر هستند: Administrator Guest Joel Group accounts نام هایی مانند نام های زیر دارند: Guests Domain Admins Managers چندین حساب سیستم وجود دارد که نمی توان آنها را مدیریت کرد و دارای معانی ویژه ای هستند: Everyone (all users) CREATOR OWNER (the owner and creator of a given object) SYSTEM (the Win32 system kernel) نکته دیگر اینکه اگر به یک حساب کاربری در یک دامنه دیگر اشاره می کنید، می توانید نام دامنه و backslash را به نام حساب اضافه کنید: Roth Consulting\Joel Roth Consulting\Domain Admins Microsoft\Gates Accounting\Managers دو دامنه از پیش تعریف شده وجود دارد که قابل اصلاح یا تغییر نیستند و دارای معانی خاصی هستند: BUILTIN (نام حساب کاربری) BUILTIN\Administators BUILTIN\Guests NT AUTHORITY (نماینده سیستم امنیتی داخلی است) NT AUTHORITY\SYSTEM Security Identifiers (SID): هر زمان که یک حساب کاربری جدید (یا گروه) ایجاد شود باید منحصر به فرد و از دیگر حساب های کاربری جدا باشد. اگر یک حساب کاربری با نام کاربر Joul ساخته شود، درحالی که قبلا یک حساب با همان userid موجود بوده باشد، ساخت حساب کاربری جدید با شکست مواجه می شود. اگر حساب کاربری به درستی ایجاد گردد، Win32 یک Security Identifier (SID) می سازد. SID یک ساختار داده است که یک حساب خاص را در یک دامنه خاص مشخص می کند. هر SID منحصر به فرد است و Win32 هیچوقت دو SID مشابه تولید نمی کند. حتی اگر شما دو حساب با نام Joel در دو دامنه (domain) داشته باشید، قطعا domain1\Joel و domain2\Joel دارای SID های متفاوت می باشند. هنگامیی که Win32 سیستم عامل می خواهد به یک حساب کاربری، حساب ماشین، حساب دامنه یا گروه (محلی و عمومی) مراجعه می کند به SID آن اشاره می کند. زمانی که ما به یک حساب یا گروه با اسم (مانند domain1\Joel) مراجعه می کنیم Win32 به دنبال SID مخصوص دامنه و حساب می گردد. برای آسان کردن کار برای ما (نه رایانه) Win32 یک SID را با یک رشته طولانی مانند زیر نمایش می دهد: S-1-5-21-143984352-578909669-1869494990-1001 این رشته منحصر به فرد یک کاربر منحصر به فرد را در یک دامنه مشخص می کند. typedef struct _SID { BYTE Revision; BYTE SubAuthorityCount; SID_IDENTIFIER_AUTHORITY IdentifierAuthority; #if ... DWORD *SubAuthority[]; #else DWORD SubAuthority[ANYSIZE_ARRAY]; #endif } SID, *PISID; Revision: نسخه SID ساختار موجود در یک SID مشخص را نشان می دهد. SubAuthorityCount: نشان دهنده تعداد مقادیر subauthority در یک SID است. IdentifierAuthority: بالاترین سطح امتیاز را که SID می تواند برای یک نوع مشخص از مدیر امنیتی مشخص کند شامل می شود. SubAuthority: اطلاعات مهمی را در SID نگه می دارد، که شامل یک یا تعداد بیشتری از مقادیر، از جنس subauthority می باشد. آخرین مقدار یک دامنه در یک (شبکه) enterprise را مشخص می کند. این داده domain identifier نامیده می شود(به غیر از داده آخر موجود در آرایه). آخرین مقدار در این سری (آرایه subauthority)، relative identifier (RID) نامیده می شود. بعد از تبدیل یک SID از فرمت باینری به یک فرمت رشته، فهم آسان تری پیدا می کند: S-R-X-Y1-Y2-Yn-1-Yn S: نشان دهنده این است که این رشته یک رشته SID است. R: نشان دهنده سطح revision است. X: نشان دهنده مقدار identifier authority است. Y: نشان دهنده یک سری از مقدار های subauthority می باشد (n مشخص کننده شماره هر مقدار است). به طور خلاصه می توان گفت که SID همان چیزی است که WIN32 استفاده می کند تا یک حساب کاربری را در یک دامنه خاص مشخص کند. Access Control Entries (ACE): ما حالا میفهمیم که Win32 برای اشاره به یک حساب کاربری، از SID به عنوان یک راه آسان استفاده می کند. اما چگونه یک حساب کاربری (یک SID) با مجموعه ای از مجوز ها مرتبط می شود؟ Win32 به permission ها به عنوان یک کنترل دسترسی (Access Control) مراجعه می کند. اگر شما یک شئ داشته باشید (به عنوان مثال، یک فایل در یک هارد درایو)، باید در مدیریت دامنه یتان(Managers domain) آن مسئله که می تواند مشکل ساز باشد (به عنوان مثال joel) را کنترل کنید، به عنوان مثال می توان فایل را برای این عنصر مشکل ساز فقط قابل خواندن قرار دهید. شما می توانید این کار با ایجاد یک Access Control Entry انجام دهید(ACE). یک ACE یک راه آسان برای نگاشت یک اکانت (SID) به مجموعه ای از permission ها است. مجموعه ای از pemission های ACE با نام permission mask(یا به طور خلاصه mask) شناخته می شوند. Win32 در داخل خود این permission mask ها رو به صورت یک مقدار DWORD چهار بایتی ذخیره می کند. هر یک از permission ها با یک بیت مشخص هماهنگ می شود. این به این معنا است که زمانی که یک ACE ساخته می شود، permission های آن به گونه ای ساخته می شوند که می توانند با OR های منطقی permission های متفاوت ایجاد کنند. $Permission = READ | WRITE | DELETE; بنابر این شما اگر می خواهید به حساب کاربری(کاربران) به عنوان مثال Joel اجازه خواندن، نوشتن و پاک کردن یک فایل را بدهید، باید یک ACE بسازید که شامل SID مدیر(یا همانjoel ) و یک permission mask (READ | WRITE | DELETE) باشد. شما می توانید ساختار کلی یک ACE را در زیر مشاهده کنید: Access Control List (ACL): هر مدیری که سرورهای پرونده را مدیریت می کند می تواند به شما بگوید که چه مجوزهایی روی یک پرونده قرار داده شده است. به عنوان مثال یک فایل می تواند شامل permission های زیر باشد: هر یک از مجموعه account/permission های کاربر ها تمام اطلاعات لازم را برای ساخت یک ACE را دارند. بر فرض که شما می خواهید چندین ACE بسازید، یک نمونه از مجموعه اطلاعات لازم account/permission در عکس بالا توصیف شده است. برای اینکه ACE ها مفید باشند، آنها باید با یکدیگر گروه بندی شوند که بتوان آنها را برای برخی از اشیاء مانند فایل ها اعمال نمود. گروهی از ACE ها با نام Access Control List (ACL) شناخته می شوند. سیستم عامل های Win32 از ACL برا گروه بندی منطقی ACE ها استفاده می کنند به طوری که آنها به راحتی می توانند بر روی یک شئ اعمال شوند. درست همانطور که یک دایرکتوری می تواند شامل گروهی از فایل ها باشد، یک ACL نیز می تواند شامل گروهی از ACE ها باشد. هر شئ Win32 که می تواند قابلیت secured را داشته باشد، از ACL برای تعیین کردن این که چه کسی به آن شئ دسترسی داشته باشد یا نداشته باشد استفاده می کند. زمانی که شما مالک شئی می شوید، یک دسته از ACE هایی را که به حساب کاربر (SID) (که در مجموعه permission ها قرار داده اید (permission mask) ) نگاشت شده است را ساخته اید. دو نوع ACL وجود دارد. نوع اول Discretionary Access Control List (DACL) می باشد، و نوع دوم System Access Control List (SACL) می باشد. تفاوت بین دو نوع مختلف ACL: DACL: این نوع ACL یک لیست از ACE ها است که مشخص می کند چه کسی حق دارد یا ندارد که به شئ دسترسی داشته باشد. برای مثال ممکن است یه یک اکانت اجازه خواندن، نوشتن یا پاک کردن را داشته باشد یا اجازه آن رد شده باشد. این همان چیزی است که هنگام تغییر مجوز ها در Windows Explorer یا File Manager تنظیم می شود. SACL: این نوع از ACL شامل لیستی از ACE ها است که نشان می دهد Win32 آیا باید رویدادهای خاصی را در Log Event وارد کند یا خیر. یک رویداد ممکن است شامل موارد زیر باشد : خواندن شئ نوشتن شئ اجرای شئ پاک کردن یک شئ تغییر مجوز های (permission) شئ گرفتن مالکیت شئ (تغییر مالک) اکثر کاربران بیشتر با DACL ها سر و کار دارند و کمتر با SACL درگیر می شوند، مگر اینکه شما سرپرستی باشید که دقیقاً باید تلاش کاربران برای دستیابی به اشیاء خاص را نظارت کند. بنابراین یک DACL نشان دهنده این است که کدام کاربران دسترسی خاصی دارند و SACL نشان دهنده این است که کدام رویداد وارد شده (logged) برای کدام کاربر است. Object Owners and Groups: گذشته از ACE های و ACL ها بیشتر اشیاء می توانند یک صاحب (owner) و گروه (group) داشته باشند. Object’s owner به طور ساده یک حساب کاربر است که object را ساخته است. انتصاب مجدد مالک به یک شئ امکان پذیر است اما فرض موجود این است که می توان کاربری را که شی را ساخته ردیابی کرد. Object’s group به طور ساده یک global group است که نشان دهنده default group سازنده می باشد. Win32 از این استفاده نمی کند اما برای سازگاری با POSIX وجود دارد. هر شئ که با یک مالک و گروه در ارتباط باشد از SID ها برای نشان دادن حساب و گروه استفاده می کنند. به بیان دیگر: یک owner و group، SID های هستند که نشان دهنده یک user account و group کسی هستند که مسئول شئ می باشند. Security Descriptors (SD): در این مرحله باید بدیهی باشد که امنیت یک شئ مستلزم ایجاد یک دسته از ACE ها (نگاشت userid ها به permission mask ها) و گروه بندی آن ها در یک لیست است(چه DACL، ACL یا هر دو). SID ها user account را مشخص می کنند، و لازم است با global group جمع گردد. پس از بدست آوردن همه این چیز ها آنها را می توان به صورت مرتب در یک ساختار بزرگ به نام توصیف کننده امنیتی (Security Descriptor) قرار داد. پس از ایجاد یک SD، می توان آن را در یک securable object مورد استفاده قرار داد. یک SD را میتوان از فایل A استخراج نموده و به عنوان مثال برای فایل B مورد استفاده قرار داد. در این حالت تمام مقادیر DACL و SACL فایل A برای فایل B ذخیره می شود. SD موجود را می توان با استخراج آن از securable object موجود دریافت کرد یا آن را از ابتدا ایجاد کرد. بنابر این شئ می تواند از یک شئ موجود(مانند یک فایل) بدست آمده یا اصلاح شده و سپس در یک securable object دیگر استفاده گردد. اصلاح، می تواند شامل هر چیزی مانند اضافه کردن ACE های جدید، تغییر permission mask در داخل یک ACE یا حذف ACE ها گردد. پایان قسمت سوم

Windows Access Control List (ACL) قسمت دوم (مفاهیم) مباحث مورد بررسی در این مقاله: Access Rights for Access-Token Objects Security Descriptors Securable Objects Access Rights for Access-Token Objects: برنامه نمی تواند لیست کنترل دسترسی یک شئ را تغییر دهد مگر اینکه برنامه حق انجام آن کار را داشته باشد. این حقوق توسط یک security descriptor در access token شئ کنترل می شود. برای گرفتن یا تنظیم کردن security descriptor برای یک access token، می توانید تابع GetKernelObjectSecurity() و تابع SetKernelObjectSecurity() را فراخوانی کنید. زمانی که تابع OpenProcessToken() یا OpenThreadToken() را برای گرفتن یک هندل access token فراخوانی می کنید، سیستم دسترسی درخواستی را در برابر DACL در security descriptor توکن بررسی می کند. موارد زیر حقوق دسترسی معتبر برای اشیاء دارای access token می باشند: DELETE، RED_CONTROL، WRITE_DAC و WRITE_OWNER دسترسی استاندارد می باشند. Access token از SYNCHRONIZE به عنوان دسترسی استاندارد پشتیبانی نمی کنند. ACCESS_SYSTEM_SECURITY برای دریافت یا تنظیم SACL در security descriptor شئ. در قسمت زیر دسترسی خاص برای access token ها ذکر شده اند: TOKEN_ADJUST_DEFAULT: مورد نیاز برای تغییر owner، primary group یا DACL یک access token. TOKEN_ADJUST_GROUPS: مورد نیاز برای تنظیم ویژگی های (attributes) یک گروه در یک access token. TOKEN_ADJUST_PRIVILEGES: مورد نیاز برای فعال یا غیر فعال کردن یک privileges در یک access token. TOKEN_ADJUST_SESSIONID: مورد نیاز برای تنظیم session ID یک access token. امتیاز(privilege) SE_TCB_NAME مورد نیاز می باشد. TOKEN_ASSIGN_PRIMARY: مورد نیاز برای متصل شدن به یک primary token یک فرایند. برای انجام این کار امتیاز SE_ASSIGNPRIMARYTOKEN_NAME مورد نیاز است. TOKEN_DUPLICATE: مورد نیاز برای کپی کردن یک access token. TOKEN_EXECUTE: STANDARD_RIGHTS_EXECUTE و TOKEN_IMPERSONATE را ترکیب می کند. TOKEN_IMPERSONATE: مورد نیاز برای متصل شدن به یک impersonation access token یک فرایند. TOKEN_QUERY: مورد نیاز برای پرس و جو درباره یک access token. TOKEN_QUERY_SOURCE: مورد نیاز برای پرسو جو در باره منبع (source) یک access token. TOKEN_READ: ترکیبی از STANDARD_RIGHTS_READ و TOKEN_QUERY می باشد. TOKEN_WRITE: ترکیبی از STANDARD_RIGHTS_WRITE، TOKEN_ADJUST_PRIVILEGES، TOKEN_ADJUST_GROUPS و TOKEN_ADJUST_DEFAULT می باشد. TOKEN_ALL_ACCESS: ترکیبی از تمام دسترسی های ممکن مرتبط با token. Security Descriptors: یک security descriptor از اطلاعات امنیتی تشکیل شده است که با یک securable object مرتبط است. یک security descriptor از یک ساختار SECURITY_DESCRIPTOR که با security information مرتبط است تشکیل شده. یک security descriptor می تواند شامل security information زیر باشد: SID های owner و primary group یک شئ. یک DACL که حقوق دسترسی، که تعیین کننده مجاز بودن یا رد شدن دسترسی یک کاربر یا گروه خاصی را مشخص می کند. یک SACL که انواع تلاش های دسترسی که سوابق حسابرسی را برای شئ ایجاد شده مشخص می کند. مجموعه ای از بیت های کنترلی که به معنای یک security descriptor یا اعضای جداگانه آن است. ویندوز تابع هایی (API) را برای تنظیم یا بازیابی کردن security information موجود در security descriptor اشیاء ارائه کرده است. بعلاوه، تابع هایی نیز برای ساخت و مقدار دهی (اولیه) کردن یک security descriptor برای یک شئ وجود دارد. برنامه هایی که با security descriptor ها در اشیاء Active Directory کار می کنند می توانند از توابع امنیتی ویندوز یا رابط های امنیتی ارائه شده توسط Active Directory Service Interfaces (ADSI) استفاده کنند. Securable Objects: یک Securable Objects یک شئ است که می تواند یک security descriptor داشته باشد. هر نوع از Securable Object مجموعه ای از دسترسی های خاص و دسترسی های عمومی را تعریف می کند. در قسمت پایین می توانید تابع هایی را مشاهده کنید که برای دستکاری اطلاعات امنیتی برخی از Securable Objects مشترک نشان می دهد. Files or directories on an NTFS file system: GetNamedSecurityInfo()، SetNamedSecurityInfo()، GetSecurityInfo()، SetSecurityInfo() Named pipes, Anonymous pipes: GetSecurityInfo()، SetSecurityInfo() Processes, Threads: GetSecurityInfo()، SetSecurityInfo() File-mapping objects: GetNamedSecurityInfo()، SetNamedSecurityInfo()، GetSecurityInfo()، SetSecurityInfo() Access tokens: SetKernelObjectSecurity()، GetKernelObjectSecurity() Window-management objects (window stations and desktops): GetSecurityInfo()، SetSecurityInfo() Registry keys: GetNamedSecurityInfo()، SetNamedSecurityInfo()، GetSecurityInfo()، SetSecurityInfo() Windows services: GetNamedSecurityInfo()، SetNamedSecurityInfo()، GetSecurityInfo()، SetSecurityInfo() Local or remote printers: GetNamedSecurityInfo()، SetNamedSecurityInfo()، GetSecurityInfo()، SetSecurityInfo() Network shares: GetNamedSecurityInfo()، SetNamedSecurityInfo()، GetSecurityInfo()، SetSecurityInfo() Interprocess synchronization objects (events, mutexes, semaphores, and waitable timers): GetNamedSecurityInfo()، SetNamedSecurityInfo()، GetSecurityInfo()، SetSecurityInfo() Job objects: GetNamedSecurityInfo()، SetNamedSecurityInfo()، GetSecurityInfo()، SetSecurityInfo() Directory service objects: این اشیاء توسط Active Directory Objects اداره شده. تصویر زیر یک مثال از رابطه بین securable object (a folder) و security descriptor را نمایش می دهد. پایان قسمت دوم