مقدمه

در لینوکس، هر فایل و پوشه دارای یک مالک کاربری و یک گروه مالک است. این ساختار مشخص می‌کند مالک فایل، اعضای گروه و سایر کاربران چه سطحی از دسترسی داشته باشند.

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

لینوکس برای حل این مشکل Permission ویژه‌ای به نام SGID یا Set Group ID ارائه می‌دهد.

SGID دو کاربرد اصلی دارد:

• روی فایل اجرایی، برنامه را با Effective GID گروه مالک فایل اجرا می‌کند.
• روی پوشه، باعث می‌شود فایل‌ها و زیرپوشه‌های جدید گروه پوشه والد را به ارث ببرند.

کاربرد SGID روی پوشه‌ها بسیار رایج‌تر است و برای ساخت مسیرهای مشترک تیمی، پوشه‌های پروژه، فضای اشتراک فایل و مسیرهای همکاری میان سرویس‌ها استفاده می‌شود. در اغلب سیستم‌ها، زیرپوشه‌های ایجادشده داخل یک پوشه SGID علاوه بر گروه مالک، خود Bit مربوط به SGID را نیز به ارث می‌برند.

در این مقاله موارد زیر را بررسی می‌کنیم:

• SGID چیست؟
• تفاوت عملکرد SGID روی فایل و پوشه
• تفاوت Real GID و Effective GID
• فعال‌سازی و حذف SGID
• تفاوت حروف s و S
• ساخت پوشه اشتراکی با SGID
• ارتباط SGID با umask و ACL
• پیدا کردن فایل‌ها و پوشه‌های SGID
• آزمایش SGID روی فایل اجرایی
• خطرات امنیتی و خطاهای رایج

SGID چیست؟

SGID مخفف عبارت Set Group ID است و یکی از Permissionهای ویژه در لینوکس محسوب می‌شود.

این Permission بسته به اینکه روی فایل اجرایی یا پوشه تنظیم شده باشد، رفتار متفاوتی دارد.

SGID on executable file:
Run with the file group's Effective GID

SGID on directory:
New entries inherit the directory group

مقدار عددی SGID برابر 2 است و در ابتدای Permission چهاررقمی قرار می‌گیرد:

2755
2770
2775

عملکرد SGID روی فایل اجرایی

زمانی که SGID روی یک فایل اجرایی فعال باشد، برنامه هنگام اجرا با Effective GID گروه مالک فایل اجرا می‌شود.

برای مثال:

File owner: root
File group: backup
Executing user: ali

Real GID: ali
Effective GID: backup

Real GID کاربر اجراکننده تغییر نمی‌کند، اما Effective GID پردازش به گروه فایل تغییر می‌کند. Supplemental Groupهای پردازش نیز در اثر اجرای معمول execve() بدون تغییر باقی می‌مانند.

این قابلیت برای برنامه‌هایی کاربرد دارد که باید به منابع متعلق به یک گروه خاص دسترسی داشته باشند، بدون اینکه کاربر را مستقیماً عضو آن گروه کنند.

برنامه SGID باید از ابتدا برای اجرای دارای دسترسی ویژه طراحی و از نظر امنیتی بررسی شده باشد.

عملکرد SGID روی پوشه

SGID روی پوشه باعث می‌شود فایل‌ها و پوشه‌های جدید، گروه پوشه والد را به ارث ببرند.

فرض کنید پوشه زیر متعلق به گروه developers است:

Directory owner: root
Directory group: developers

بدون SGID، فایلی که کاربر ali ایجاد می‌کند ممکن است گروه اصلی خود کاربر را دریافت کند:

File owner: ali
File group: ali

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

File owner: ali
File group: developers

این رفتار مدیریت پوشه‌های تیمی را ساده می‌کند و از پراکندگی Group Ownership جلوگیری می‌کند. زیرپوشه جدید نیز معمولاً SGID را از پوشه والد به ارث می‌برد.

تفاوت SGID روی فایل و پوشه

ساختار عددی SGID

Permissionهای ویژه در رقم اول Mode چهاررقمی قرار می‌گیرند:

برای مثال:

2755

تجزیه:

2 = SGID
7 = Owner: Read, Write, and Execute
5 = Group: Read and Execute
5 = Other: Read and Execute

نمایش نمادین:

-rwxr-sr-x

نمونه SGID روی پوشه گروهی

2770

تجزیه:

2 = SGID
7 = Owner: Full Access
7 = Group: Full Access
0 = Other: No Access

نمایش:

drwxrws---

ترکیب SGID و Sticky Bit

مقادیر Permissionهای ویژه با یکدیگر جمع می‌شوند.

2 = SGID
1 = Sticky Bit
3 = SGID and Sticky Bit

برای مثال:

3770

این Permission روی یک پوشه گروهی:

• گروه را برای فایل‌های جدید به ارث می‌گذارد.
• مانع حذف یا تغییر نام فایل دیگران توسط اعضای عادی می‌شود.

مشاهده SGID با دستور ls

برای مشاهده Permission فایل:

ls -l application

نمونه فایل دارای SGID:

-rwxr-sr-x 1 root backup 24576 Jul 27 10:00 application

حرف s در جایگاه Execute گروه نشان می‌دهد SGID فعال است.

برای پوشه:

ls -ld /srv/developers

خروجی:

drwxrws--- 5 root developers 4096 Jul 27 10:00 /srv/developers

مشاهده SGID با دستور stat

stat -c '%a %A %U %G %n' /srv/developers

خروجی:

2770 drwxrws--- root developers /srv/developers

در Permission عددی، رقم اول 2 نشان‌دهنده SGID است.

فعال‌کردن SGID به روش نمادین

برای فعال‌کردن SGID:

sudo chmod g+s /srv/developers

حرف g به بخش Group و حرف s به Set Group ID اشاره می‌کند. این ساختار در Syntax استاندارد chmod برای تغییر Set-Group-ID استفاده می‌شود.

بررسی:

ls -ld /srv/developers

خروجی:

drwxrws--- 5 root developers 4096 Jul 27 10:00 /srv/developers

فعال‌کردن SGID به روش عددی

برای پوشه‌ای با Permission کامل مالک و گروه:

sudo chmod 2770 /srv/developers

برای پوشه‌ای که Other امکان خواندن و ورود دارد:

sudo chmod 2775 /srv/developers

برای فایل اجرایی عمومی:

sudo chmod 2755 application

حذف SGID

روش نمادین و واضح:

sudo chmod g-s /srv/developers

بررسی:

stat -c '%a %A %n' /srv/developers

خروجی احتمالی:

770 drwxrwx--- /srv/developers

برای حذف صریح تمام Set-ID Bitها:

sudo chmod a-s /srv/developers

این دستور SUID و SGID را در صورت وجود حذف می‌کند.

نکته مهم درباره chmod روی پوشه SGID

در GNU chmod، اجرای دستور ساده‌ای مانند زیر روی یک پوشه ممکن است SGID موجود را حفظ کند:

sudo chmod 770 /srv/developers

برای حذف قابل‌پیش‌بینی SGID بهتر است آن را صریحاً حذف کنید:

sudo chmod g-s /srv/developers

روش دیگر:

sudo chmod =770 /srv/developers

GNU Coreutils توضیح می‌دهد که Modeهای معمول سه یا چهاررقمی ممکن است Set-ID Bitهای پوشه را حفظ کنند، مگر اینکه حذف آن‌ها صریحاً درخواست شود.

تفاوت s و S

SGID ممکن است در خروجی ls با حرف کوچک s یا حرف بزرگ S نمایش داده شود.

حرف کوچک s

اگر SGID و Execute گروه هر دو فعال باشند:

-rwxr-sr-x

یا برای پوشه:

drwxrws---

حرف کوچک s نمایش داده می‌شود.

حرف بزرگ S

اگر SGID فعال باشد اما Group Execute فعال نباشد:

-rwxr-Sr--

یا:

drwxrwS---

نمونه ایجاد این وضعیت:

sudo chmod 2760 /srv/developers

بررسی:

ls -ld /srv/developers

خروجی:

drwxrwS--- 5 root developers 4096 Jul 27 10:00 /srv/developers

حرف S نشان می‌دهد SGID فعال است، اما گروه مجوز ورود یا Execute ندارد.

برای پوشه اشتراکی، معمولاً باید Execute گروه فعال باشد:

sudo chmod g+x /srv/developers

یا:

sudo chmod 2770 /srv/developers

ایجاد پوشه اشتراکی با SGID

فرض کنید کاربران ali و reza باید در یک پروژه مشترک همکاری کنند.

مرحله اول: ایجاد گروه

sudo groupadd developers

بررسی:

getent group developers

خروجی:

developers:x:1500:

مرحله دوم: افزودن کاربران به گروه

sudo usermod -aG developers ali
sudo usermod -aG developers reza

بررسی:

id ali
id reza

نمونه خروجی:

uid=1001(ali) gid=1001(ali) groups=1001(ali),1500(developers)
uid=1002(reza) gid=1002(reza) groups=1002(reza),1500(developers)

کاربران باید از Session فعلی خارج و دوباره وارد شوند تا عضویت گروه جدید اعمال شود.

مرحله سوم: ایجاد پوشه پروژه

sudo mkdir -p /srv/developers

تنظیم مالک و گروه:

sudo chown root:developers /srv/developers

مرحله چهارم: فعال‌کردن SGID

sudo chmod 2770 /srv/developers

بررسی:

stat -c '%a %A %U %G %n' /srv/developers

خروجی:

2770 drwxrws--- root developers /srv/developers

مرحله پنجم: ایجاد فایل توسط ali

sudo -u ali touch /srv/developers/ali-file.txt

بررسی:

stat -c '%U %G %a %n' /srv/developers/ali-file.txt

خروجی احتمالی:

ali developers 644 /srv/developers/ali-file.txt

مالک فایل ali است، اما گروه آن از پوشه والد به ارث رسیده است:

User owner: ali
Group owner: developers

مرحله ششم: ایجاد زیرپوشه

sudo -u ali mkdir /srv/developers/backend

بررسی:

stat -c '%a %A %U %G %n' /srv/developers/backend

خروجی احتمالی:

2755 drwxr-sr-x ali developers /srv/developers/backend

زیرپوشه:

• گروه developers را به ارث برده است.
• SGID را نیز دریافت کرده است.

چرا reza ممکن است نتواند فایل ali را ویرایش کند؟

SGID فقط Group Ownership را مدیریت می‌کند و به‌تنهایی Permission نوشتن گروه را اضافه نمی‌کند.

ممکن است فایل ایجادشده دارای Permission زیر باشد:

-rw-r--r--

یا:

File mode: 644

در این حالت اعضای گروه فقط می‌توانند فایل را بخوانند.

تلاش برای نوشتن:

sudo -u reza \
bash -c 'echo "New data" >> /srv/developers/ali-file.txt'

خروجی احتمالی:

bash: /srv/developers/ali-file.txt: Permission denied

علت این مشکل معمولاً umask کاربر سازنده است.

ترکیب SGID با umask

SGID گروه مالک را به ارث می‌دهد، اما Permission فایل‌های جدید همچنان تحت تأثیر umask است.

اگر umask برابر 022 باشد:

New file: 644
New directory: 755

در نتیجه گروه فایل مجوز Write ندارد.

برای محیط همکاری گروهی می‌توان از مقدار زیر استفاده کرد:

umask 002

نتیجه معمول:

New file: 664
New directory: 775

با SGID:

File owner: ali
File group: developers
File mode: 664

اعضای گروه می‌توانند فایل را ویرایش کنند.

آزمایش با umask برابر 002

sudo -u ali bash -c '
    umask 002
    touch /srv/developers/shared-file.txt
    mkdir /srv/developers/shared-directory
'

بررسی:

stat -c '%a %U %G %n' \
/srv/developers/shared-file.txt \
/srv/developers/shared-directory

خروجی:

664 ali developers /srv/developers/shared-file.txt
2775 ali developers /srv/developers/shared-directory

تنظیم دائمی umask برای پوشه اشتراکی

تنظیم umask در Shell کاربر روی تمام فایل‌های آن Session اثر می‌گذارد و فقط به یک پوشه محدود نیست.

برای اعمال کنترل دقیق‌تر روی یک پوشه اشتراکی، استفاده از Default ACL معمولاً مناسب‌تر است.

ترکیب SGID با Default ACL

ابتدا بسته ACL را نصب کنید.

در Ubuntu:

sudo apt update
sudo apt install acl -y

در AlmaLinux:

sudo dnf install acl -y

تعریف Default ACL برای گروه:

sudo setfacl -m \
d:u::rwx,\
d:g::rwx,\
d:m::rwx,\
d:o::--- \
/srv/developers

اعمال ACL روی خود پوشه:

sudo setfacl -m \
u::rwx,\
g::rwx,\
m::rwx,\
o::--- \
/srv/developers

بررسی:

getfacl /srv/developers

خروجی نمونه:

# file: srv/developers
# owner: root
# group: developers
# flags: -s-
user::rwx
group::rwx
mask::rwx
other::---
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::---

عبارت زیر نشان می‌دهد SGID فعال است:

# flags: -s-

آزمایش فایل جدید با Default ACL

sudo -u ali touch /srv/developers/acl-file.txt

بررسی:

getfacl /srv/developers/acl-file.txt

خروجی احتمالی:

# file: srv/developers/acl-file.txt
# owner: ali
# group: developers
user::rw-
group::rwx                  #effective:rw-
mask::rw-
other::---

فایل معمولی معمولاً Execute دریافت نمی‌کند، اما گروه امکان خواندن و نوشتن خواهد داشت.

SGID و Sticky Bit در پوشه مشترک

در پوشه‌ای که همه اعضای گروه امکان Write دارند، هر عضو ممکن است بتواند فایل‌های دیگران را حذف یا Rename کند؛ زیرا حذف فایل به Permission پوشه والد وابسته است.

برای جلوگیری از این رفتار می‌توان Sticky Bit را نیز فعال کرد:

sudo chmod 3770 /srv/developers

بررسی:

stat -c '%a %A %U %G %n' /srv/developers

خروجی:

3770 drwxrws--T root developers /srv/developers

در این حالت:

SGID: Enabled
Sticky Bit: Enabled
Group access: Full
Other access: None

حرف T طبیعی است؛ زیرا Other مجوز Execute ندارد.

با Sticky Bit، حذف یا Rename فایل فقط برای افراد زیر مجاز خواهد بود:

File owner
Directory owner
root user

انتخاب Permission مناسب پوشه SGID

پوشه خصوصی تیمی

sudo chmod 2770 /srv/team

Owner: Full Access
Group: Full Access
Other: No Access

پوشه تیمی با امکان خواندن سایر کاربران

sudo chmod 2775 /srv/team

Owner: Full Access
Group: Full Access
Other: Read and Execute

پوشه گروهی فقط خواندنی

sudo chmod 2750 /srv/reports

Owner: Full Access
Group: Read and Execute
Other: No Access

پوشه همراه Sticky Bit

sudo chmod 3770 /srv/team

SGID: Enabled
Sticky Bit: Enabled

SGID روی فایل اجرایی

اگر SGID روی یک فایل اجرایی فعال باشد، Effective GID پردازش به گروه مالک فایل تغییر می‌کند. این تغییر در شرایطی مانند فعال‌بودن no_new_privs، Mount شدن فایل‌سیستم با nosuid یا اجرای پردازش تحت Tracing ممکن است اعمال نشود.

مثال:

File group: backup
Executing user: ali

Real GID: ali
Effective GID: backup

این قابلیت باید فقط برای Binaryهای بررسی‌شده استفاده شود.

آزمایش کنترل‌شده SGID روی فایل اجرایی

برای مشاهده Real GID و Effective GID می‌توان یک برنامه ساده آزمایشی ساخت.

این آزمایش را فقط روی محیط آزمایشی انجام دهید و فایل SGID را پس از پایان حذف کنید.

مرحله اول: ساخت فایل C

nano /tmp/sgid-demo.c

محتوا:

#include <stdio.h>
#include <unistd.h>

int main(void) {
    printf("Real UID: %d\n", getuid());
    printf("Effective UID: %d\n", geteuid());
    printf("Real GID: %d\n", getgid());
    printf("Effective GID: %d\n", getegid());
    return 0;
}

مرحله دوم: نصب Compiler

Ubuntu:

sudo apt update
sudo apt install build-essential -y

AlmaLinux:

sudo dnf install gcc -y

مرحله سوم: Compile

gcc \
-Wall \
-Wextra \
-O2 \
-o /tmp/sgid-demo \
/tmp/sgid-demo.c

بررسی:

ls -l /tmp/sgid-demo

خروجی:

-rwxr-xr-x 1 ali ali 16064 Jul 27 10:00 /tmp/sgid-demo

مرحله چهارم: ساخت گروه آزمایشی

sudo groupadd sgidtest

بررسی:

getent group sgidtest

خروجی:

sgidtest:x:1600:

مرحله پنجم: انتقال Binary

sudo mkdir -p /usr/local/libexec

sudo install \
-o root \
-g sgidtest \
-m 0755 \
/tmp/sgid-demo \
/usr/local/libexec/sgid-demo

بررسی:

stat -c '%a %A %U %G %n' \
/usr/local/libexec/sgid-demo

خروجی:

755 -rwxr-xr-x root sgidtest /usr/local/libexec/sgid-demo

مرحله ششم: اجرای عادی

/usr/local/libexec/sgid-demo

نمونه خروجی:

Real UID: 1001
Effective UID: 1001
Real GID: 1001
Effective GID: 1001

مرحله هفتم: فعال‌کردن SGID

sudo chmod g+s /usr/local/libexec/sgid-demo

بررسی:

stat -c '%a %A %U %G %n' \
/usr/local/libexec/sgid-demo

خروجی:

2755 -rwxr-sr-x root sgidtest /usr/local/libexec/sgid-demo

مرحله هشتم: اجرای مجدد

/usr/local/libexec/sgid-demo

خروجی احتمالی:

Real UID: 1001
Effective UID: 1001
Real GID: 1001
Effective GID: 1600

در این مثال:

Real GID: Calling user's primary group
Effective GID: File group

مرحله نهم: پاک‌سازی

حذف SGID:

sudo chmod g-s /usr/local/libexec/sgid-demo

حذف فایل‌ها:

sudo rm -f /usr/local/libexec/sgid-demo
rm -f /tmp/sgid-demo /tmp/sgid-demo.c

حذف گروه آزمایشی:

sudo groupdel sgidtest

SGID روی Shell Script

Linux مانند بیشتر سیستم‌های Unix مدرن، Set-User-ID و Set-Group-ID را روی Interpreter Scriptها نادیده می‌گیرد. بنابراین قراردادن SGID روی فایل Bash، Python یا PHP معمولاً باعث اجرای Script با گروه مالک نمی‌شود.

مثال:

sudo chmod 2755 backup.sh

ممکن است خروجی زیر نمایش داده شود:

-rwxr-sr-x 1 root backup 512 Jul 27 10:00 backup.sh

اما Kernel هنگام اجرای Script، SGID را اعمال نمی‌کند.

راهکارهای مناسب‌تر:

Restricted sudoers rule
systemd service
Compiled and audited helper
Linux capabilities
Dedicated service account

تأثیر گزینه nosuid

اگر فایل‌سیستم با گزینه nosuid Mount شده باشد، SUID و SGID روی فایل‌های اجرایی هنگام اجرا نادیده گرفته می‌شوند. همین محدودیت می‌تواند File Capabilityهای اجرایی را نیز بی‌اثر کند.

بررسی:

findmnt -T /path/to/application \
-o TARGET,FSTYPE,OPTIONS

خروجی نمونه:

TARGET FSTYPE OPTIONS
/tmp   tmpfs  rw,nosuid,nodev

وجود گزینه زیر مهم است:

nosuid

گزینه nosuid مانع کاربرد اجرایی SGID می‌شود. رفتار ارث‌بری گروه روی Directory به Permission و فایل‌سیستم مربوط است و با کاربرد اجرایی فایل یکسان نیست.

بررسی no_new_privs

اگر Process دارای no_new_privs باشد، اجرای فایل SGID نباید Privilege جدیدی برای آن ایجاد کند.

بررسی Shell جاری:

grep '^NoNewPrivs:' /proc/$$/status

خروجی:

NoNewPrivs:	0

مقدار 1 نشان می‌دهد Process اجازه کسب Privilege جدید از طریق Set-ID یا File Capability را ندارد.

پیدا کردن فایل‌های SGID

برای پیدا کردن تمام فایل‌های SGID در فایل‌سیستم جاری:

sudo find / \
-xdev \
-type f \
-perm -2000 \
-ls 2>/dev/null

گزینه‌ها:

-xdev = Stay on the current filesystem
-type f = Regular files only
-perm -2000 = SGID enabled
-ls = Detailed output

نمایش فقط مسیر فایل‌ها

sudo find / \
-xdev \
-type f \
-perm -2000 \
-print 2>/dev/null

نمونه خروجی:

/usr/bin/wall
/usr/bin/write
/usr/bin/ssh-agent

فهرست واقعی به توزیع و Packageهای نصب‌شده بستگی دارد.

پیدا کردن پوشه‌های SGID

sudo find / \
-xdev \
-type d \
-perm -2000 \
-ls 2>/dev/null

جست‌وجو در /srv:

find /srv \
-type d \
-perm -2000 \
-ls

این دستور برای شناسایی پوشه‌های اشتراکی و بررسی ارث‌بری گروه مفید است.

پیدا کردن SUID و SGID

برای فایل‌هایی که حداقل یکی از Bitهای SUID یا SGID را دارند:

sudo find / \
-xdev \
-type f \
-perm /6000 \
-ls 2>/dev/null

مقادیر:

4000 = SUID
2000 = SGID
6000 = SUID or SGID search mask

ثبت Baseline فایل‌های SGID

sudo find / \
-xdev \
-type f \
-perm -2000 \
-printf '%m %u %g %p\n' 2>/dev/null \
| sort \
> /root/sgid-baseline.txt

مشاهده:

less /root/sgid-baseline.txt

در بررسی بعدی:

sudo find / \
-xdev \
-type f \
-perm -2000 \
-printf '%m %u %g %p\n' 2>/dev/null \
| sort \
> /root/sgid-current.txt

مقایسه:

diff -u \
/root/sgid-baseline.txt \
/root/sgid-current.txt

فایل SGID جدید الزاماً مخرب نیست، اما باید دلیل ایجاد آن مشخص شود.

بررسی Package مالک فایل SGID

در Ubuntu و Debian:

dpkg -S /path/to/application

در AlmaLinux، Rocky Linux و RHEL:

rpm -qf /path/to/application

نمونه:

package-name: /path/to/application

اگر فایل متعلق به Package شناخته‌شده‌ای نباشد، موارد زیر را بررسی کنید:

• منبع فایل
• تاریخ ایجاد و تغییر
• مالک و گروه
• Hash
• Parent Directory
• فرآیند نصب برنامه
• نیاز واقعی به SGID

بررسی Hash فایل SGID

sha256sum /path/to/application

برای تمام فایل‌های SGID:

sudo find /usr/bin /usr/sbin /usr/local /opt \
-type f \
-perm -2000 \
-exec sha256sum {} +

Hash باید با Baseline معتبر یا Package رسمی مقایسه شود.

بررسی تغییرات Package

Ubuntu:

sudo dpkg -V package-name

AlmaLinux:

sudo rpm -V package-name

خروجی باید براساس مستندات ابزار Package Manager تفسیر شود.

پیدا کردن فایل‌های SGID قابل‌نوشتن

فایل SGID نباید توسط کاربران یا گروه‌های غیرقابل‌اعتماد قابل‌نوشتن باشد.

جست‌وجوی فایل‌های SGID دارای Write برای Other:

sudo find / \
-xdev \
-type f \
-perm -2000 \
-perm -0002 \
-ls 2>/dev/null

جست‌وجوی Write برای Group یا Other:

sudo find / \
-xdev \
-type f \
-perm -2000 \
\( -perm -0020 -o -perm -0002 \) \
-ls 2>/dev/null

هر نتیجه باید فوراً بررسی شود.

بررسی Parent Directory فایل SGID

namei -l /usr/local/libexec/application

خروجی امن نمونه:

f: /usr/local/libexec/application
drwxr-xr-x root root /
drwxr-xr-x root root usr
drwxr-xr-x root root local
drwxr-xr-x root root libexec
-rwxr-sr-x root backup application

پوشه والد نباید توسط کاربران غیرقابل‌اعتماد قابل‌نوشتن باشد.

اثر chown روی SGID

تغییر مالک یا گروه یک فایل ممکن است Bit مربوط به SGID را پاک کند.

sudo chown root:newgroup application

بررسی مجدد:

stat -c '%a %A %U %G %n' application

GNU Coreutils توضیح می‌دهد که chown در بعضی شرایط Set-User-ID یا Set-Group-ID را حذف می‌کند.

پس از هر تغییر مالکیت، Permission ویژه را دوباره بررسی کنید.

اثر chmod روی SGID فایل

اگر مالک فایل گروهی را روی فایل SGID تنظیم کند که عضو آن نیست، Linux ممکن است Bit مربوط به SGID را پاک کند؛ مگر اینکه Process دارای Privilege لازم باشد.

بررسی بعد از تغییر:

stat -c '%a %A %U %G %n' application

SGID روی فایل بدون Group Execute

در Linux، SGID روی یک فایل عادی که Group Execute ندارد ممکن است در بعضی فایل‌سیستم‌ها با Mandatory Locking قدیمی مرتبط باشد. این مدل امروزه کاربرد عمومی محدودی دارد و نباید برای طراحی سیستم جدید به آن متکی بود.

نمونه:

-rw-r-Sr--

برای برنامه اجرایی SGID، مجوز Execute گروه معمولاً باید وجود داشته باشد:

sudo chmod 2755 application

SGID در Docker و Container

در Volumeهای Docker، Group Ownership براساس GID عددی مدیریت می‌شود.

بررسی هویت Process داخل Container:

docker exec app id

خروجی نمونه:

uid=1000(app) gid=1000(app) groups=1000(app),1500(developers)

تنظیم گروه Volume روی Host:

sudo chown root:1500 /opt/app/shared

فعال‌کردن SGID:

sudo chmod 2770 /opt/app/shared

بررسی:

stat -c '%a %u %g %n' /opt/app/shared

خروجی:

2770 0 1500 /opt/app/shared

نام گروه روی Host و Container ممکن است متفاوت باشد؛ GID عددی باید هماهنگ باشد.

SGID در NFS

عملکرد SGID در NFS به عوامل زیر وابسته است:

UID and GID mapping
NFS server filesystem
Export options
NFS version
Client mount options
Server-side permissions

بررسی Mount:

findmnt -T /mnt/shared \
-o TARGET,FSTYPE,OPTIONS

در NFS، گروه فایل‌ها براساس شناسه‌های عددی و تنظیمات Server و Client مدیریت می‌شود. اختلاف GID می‌تواند باعث نمایش گروه اشتباه یا خطای دسترسی شود.

SGID و SELinux

SGID یکی از Permissionهای Unix است، اما SELinux یک لایه جداگانه کنترل دسترسی ایجاد می‌کند.

وضعیت SELinux:

getenforce

خروجی:

Enforcing

بررسی Context:

ls -Zd /srv/developers

خطاهای اخیر:

sudo ausearch -m AVC -ts recent

بازیابی Context استاندارد:

sudo restorecon -Rv /srv/developers

اگر Group Ownership و Permission صحیح باشند اما سرویس همچنان با خطا مواجه شود، SELinux Context و Policy را بررسی کنید.

SGID و AppArmor

در Ubuntu ممکن است AppArmor دسترسی برنامه را محدود کند.

بررسی:

sudo aa-status

Logها:

sudo journalctl -k | grep -i apparmor

SGID جایگزین تنظیمات صحیح AppArmor نیست.

استفاده از install برای ساخت پوشه SGID

برای ایجاد پوشه همراه با مالکیت و Permission مشخص:

sudo install \
-d \
-o root \
-g developers \
-m 2770 \
/srv/developers

بررسی:

stat -c '%a %A %U %G %n' /srv/developers

خروجی:

2770 drwxrws--- root developers /srv/developers

این روش برای Scriptهای نصب و Deployment مناسب است.

استفاده از mkdir و chmod

sudo mkdir -p /srv/developers
sudo chown root:developers /srv/developers
sudo chmod 2770 /srv/developers

GNU mkdir از Modeهای chmod پشتیبانی می‌کند، اما رفتار Permissionهای ویژه و umask باید پس از ساخت بررسی شود.

اصلاح پوشه‌ای که فایل‌های قدیمی دارد

فعال‌کردن SGID فقط روی فایل‌ها و پوشه‌هایی اثر می‌گذارد که بعداً ایجاد می‌شوند. Group Ownership فایل‌های قدیمی خودکار تغییر نمی‌کند.

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

sudo chown -R :developers /srv/developers

یا کنترل‌شده‌تر:

sudo find /srv/developers \
-xdev \
-exec chgrp developers {} +

سپس SGID را روی تمام پوشه‌ها فعال کنید:

sudo find /srv/developers \
-xdev \
-type d \
-exec chmod g+s {} +

Permission فایل‌ها:

sudo find /srv/developers \
-xdev \
-type f \
-exec chmod 660 {} +

Permission پوشه‌ها:

sudo find /srv/developers \
-xdev \
-type d \
-exec chmod 2770 {} +

قبل از اجرای بازگشتی، مسیر و نیاز Permission را بررسی کنید.

اعمال SGID فقط روی پوشه‌ها

sudo find /srv/project \
-type d \
-exec chmod g+s {} +

بررسی:

find /srv/project \
-type d \
-perm -2000 \
-printf '%m %u %g %p\n'

این روش از تنظیم SGID روی فایل‌های معمولی جلوگیری می‌کند.

حذف SGID از تمام فایل‌های یک مسیر

ابتدا فایل‌های دارای SGID را مشاهده کنید:

find /srv/project \
-type f \
-perm -2000 \
-ls

سپس در صورت تأیید:

sudo find /srv/project \
-type f \
-perm -2000 \
-exec chmod g-s {} +

حذف SGID از پوشه‌ها

sudo find /srv/project \
-type d \
-perm -2000 \
-exec chmod g-s {} +

بررسی:

find /srv/project \
-type d \
-perm -2000 \
-ls

رفع خطاهای رایج SGID

فایل‌های جدید گروه پوشه را به ارث نمی‌برند

ابتدا Permission پوشه را بررسی کنید:

stat -c '%a %A %U %G %n' /srv/developers

خروجی باید شامل 2 یا s باشد:

2770 drwxrws--- root developers /srv/developers

موارد احتمالی:

• SGID فعال نیست.
• فایل در Subdirectory بدون SGID ساخته شده است.
• فایل‌سیستم رفتار متفاوتی دارد.
• برنامه پس از ساخت فایل، گروه را تغییر می‌دهد.
• فایل داخل Mount دیگری ایجاد شده است.
• NFS یا CIFS Mapping متفاوت است.

بررسی فایل‌سیستم:

findmnt -T /srv/developers \
-o TARGET,FSTYPE,OPTIONS

گروه صحیح است اما سایر اعضا نمی‌توانند بنویسند

Permission فایل را بررسی کنید:

stat -c '%a %A %U %G %n' \
/srv/developers/file.txt

نمونه مشکل:

644 -rw-r--r-- ali developers file.txt

گروه Write ندارد.

راهکار:

• تنظیم umask 002
• استفاده از Default ACL
• تغییر Permission فایل‌های موجود

مثال:

sudo chmod 660 /srv/developers/file.txt

SGID با S بزرگ نمایش داده می‌شود

نمونه:

drwxrwS---

گروه مجوز Execute ندارد.

اصلاح:

sudo chmod g+x /srv/developers

یا:

sudo chmod 2770 /srv/developers

chmod 770 باعث حذف SGID نشده است

در GNU chmod، Mode معمول ممکن است SGID پوشه را حفظ کند.

حذف صریح:

sudo chmod g-s /srv/developers

بررسی:

stat -c '%a %A %n' /srv/developers

SGID بعد از chown حذف شده است

تغییر مالکیت یا گروه ممکن است SGID فایل را پاک کند.

بررسی:

stat -c '%a %A %U %G %n' application

فقط در صورت نیاز واقعی و پس از بررسی امنیتی، دوباره فعال کنید:

sudo chmod g+s application

SGID روی Script کار نمی‌کند

Linux Set-ID Bitها را روی Interpreter Scriptها نادیده می‌گیرد.

گزینه‌های جایگزین:

Restricted sudoers rule
systemd service
Dedicated group membership
Compiled helper
Linux capabilities

SGID روی Binary اثر ندارد

بررسی Permission:

stat -c '%a %A %U %G %n' application

بررسی Mount:

findmnt -T application \
-o TARGET,FSTYPE,OPTIONS

بررسی NoNewPrivs:

grep '^NoNewPrivs:' /proc/$$/status

دلایل احتمالی:

Filesystem mounted nosuid
no_new_privs enabled
Program is being ptraced
File is an interpreter script
Group owner is not expected
SELinux or AppArmor restriction
Container security configuration

خطای Operation not permitted

نمونه:

chmod: changing permissions of 'application': Operation not permitted

دلایل احتمالی:

• کاربر مالک فایل نیست.
• دسترسی root وجود ندارد.
• فایل‌سیستم Read-only است.
• فایل Immutable است.
• مسیر روی NFS قرار دارد.
• Container Capability لازم را ندارد.

با sudo آزمایش کنید:

sudo chmod g+s application

بررسی Immutable Attribute

lsattr application

خروجی:

----i----------------- application

حذف موقت:

sudo chattr -i application

پس از تغییر، در صورت نیاز:

sudo chattr +i application

کاربران عضو گروه هستند اما دسترسی ندارند

عضویت را بررسی کنید:

id ali

کاربر باید Session جدید ایجاد کند:

su - ali

یا Logout و Login کند.

بررسی گروه‌ها در Session جدید:

id

همچنین Permission پوشه‌های والد را بررسی کنید:

namei -l /srv/developers/file.txt

فایل‌ها گروه صحیح دارند اما حذف می‌شوند

SGID مانع حذف فایل دیگران نمی‌شود.

برای محدودکردن حذف و Rename، Sticky Bit را فعال کنید:

sudo chmod 3770 /srv/developers

یا ساختار ACL و Workflow پروژه را بازطراحی کنید.

نکات امنیتی و بهترین روش‌ها

• SGID روی Directory برای پوشه‌های تیمی کاربرد مناسبی دارد.
• SGID را فقط روی Binaryهای بررسی‌شده فعال کنید.
• فایل SGID نباید توسط کاربران غیرقابل‌اعتماد قابل‌نوشتن باشد.
• Parent Directory فایل SGID باید امن باشد.
• برای پوشه‌های مشترک از گروه اختصاصی استفاده کنید.
• SGID را همراه با umask یا Default ACL تنظیم کنید.
• SGID به‌تنهایی Group Write ایجاد نمی‌کند.
• برای جلوگیری از حذف فایل دیگران Sticky Bit را بررسی کنید.
• فایل‌های SGID سیستم را به‌صورت دوره‌ای فهرست کنید.
• فایل‌های SGID ناشناخته در /tmp، /opt و /usr/local را بررسی کنید.
• پس از chown و chmod، SGID را دوباره بررسی کنید.
• روی Scriptها به SGID متکی نباشید.
• گزینه‌های nosuid و no_new_privs را در عیب‌یابی بررسی کنید.
• SELinux و AppArmor را در نظر بگیرید.
• در Docker و NFS از تطابق GID عددی مطمئن شوید.
• عملیات بازگشتی را ابتدا با find پیش‌نمایش کنید.
• اصل کمترین سطح دسترسی را رعایت کنید.

اشتباهات رایج

موارد زیر از اشتباهات متداول هنگام استفاده از SGID هستند:

• تصور اینکه SGID به گروه Write می‌دهد
• تنظیم SGID بدون اصلاح Group Ownership
• استفاده از umask 022 در پوشه همکاری گروهی
• فراموش‌کردن Default ACL
• تصور اینکه SGID مانع حذف فایل دیگران می‌شود
• فعال‌کردن SGID روی Script
• فعال‌کردن SGID روی Binary قابل‌نوشتن
• قراردادن Binary SGID در Directory قابل‌نوشتن
• نادیده‌گرفتن حرف بزرگ S
• نادیده‌گرفتن nosuid
• نادیده‌گرفتن no_new_privs
• حذف SGID فایل سیستمی بدون بررسی
• اجرای chown بدون بررسی مجدد SGID
• ناهماهنگی GID در Docker یا NFS
• اجرای بازگشتی روی مسیر اشتباه
• استفاده از Permission بسیار باز مانند 2777

چک‌لیست نهایی SGID

پس از تنظیم SGID موارد زیر را بررسی کنید:

• مسیر هدف فایل است یا پوشه.
• مالک و گروه صحیح هستند.
• گروه موردنظر وجود دارد.
• کاربران عضو گروه هستند.
• کاربران Session جدید ایجاد کرده‌اند.
• SGID با g+s یا Mode عددی فعال شده است.
• خروجی ls شامل s یا S است.
• Permission عددی با stat بررسی شده است.
• فایل جدید گروه پوشه را به ارث می‌برد.
• زیرپوشه جدید SGID را به ارث می‌برد.
• Permission گروه برای همکاری کافی است.
• umask کاربران بررسی شده است.
• Default ACL در صورت نیاز تنظیم شده است.
• Sticky Bit در صورت نیاز فعال شده است.
• فایل SGID قابل‌نوشتن توسط کاربران غیرمجاز نیست.
• Parent Directory امن است.
• Mount با nosuid محدود نشده است.
• SELinux یا AppArmor مانع دسترسی نیست.
• GID در Container یا NFS هماهنگ است.
• فایل‌ها و پوشه‌های قدیمی جداگانه اصلاح شده‌اند.

دستورات پرکاربرد SGID

فعال‌کردن SGID:

chmod g+s path

فعال‌کردن SGID روی پوشه خصوصی گروه:

chmod 2770 directory

فعال‌کردن SGID روی پوشه عمومی‌تر:

chmod 2775 directory

حذف SGID:

chmod g-s path

بررسی Permission:

ls -ld directory

بررسی عددی:

stat -c '%a %A %U %G %n' path

ایجاد پوشه SGID:

sudo install \
-d \
-o root \
-g developers \
-m 2770 \
/srv/developers

پیداکردن فایل‌های SGID:

sudo find / \
-xdev \
-type f \
-perm -2000 \
-ls 2>/dev/null

پیداکردن پوشه‌های SGID:

sudo find / \
-xdev \
-type d \
-perm -2000 \
-ls 2>/dev/null

فعال‌کردن SGID روی تمام پوشه‌ها:

sudo find /srv/project \
-type d \
-exec chmod g+s {} +

ترکیب SGID و Sticky Bit:

chmod 3770 directory

بررسی Mount:

findmnt -T path \
-o TARGET,FSTYPE,OPTIONS

جمع‌بندی

SGID یکی از Permissionهای ویژه لینوکس است که روی فایل و پوشه دو رفتار متفاوت دارد.

روی فایل اجرایی:

Effective GID = File group

روی پوشه:

New file group = Parent directory group

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

chmod g+s path

یا به‌صورت عددی:

chmod 2770 directory

حرف s در محل Execute گروه نشان می‌دهد SGID و Group Execute هر دو فعال هستند. حرف S نشان می‌دهد SGID فعال است، اما Group Execute وجود ندارد.

در پوشه‌های اشتراکی، SGID فقط Group Ownership را به ارث می‌دهد و به‌تنهایی Permission نوشتن گروه را تضمین نمی‌کند. برای همکاری کامل گروهی باید umask، Default ACL و Permissionهای فایل نیز بررسی شوند.

همچنین SGID مانع حذف فایل‌های متعلق به کاربران دیگر نمی‌شود. برای این هدف باید Sticky Bit یا ساختار دسترسی مناسب دیگری تعریف شود.

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