ولی باز باید سودو رو بنویسیم تا کار کنه که!
میتونید بیت setuid رو فعال کنید و مالکیت فایل رو هم به روت بدید تا برنامه با دسترسی روت اجرا بشه.
البته اینجوری هر کاربری که میتونه اون برنامه رو با دسترسی روت اجرا کنه. از نظر امنیتی، سیستم تبدیل به آبکش میشه.
مالکیت روت و بیت setuid همراه هم باید با احتیاط و فقط برای برنامههایی استفاده بشن که اول کاربر رو احراز هویت میکنند.
خود دستور sudo و همینطور passwd و pkexec تحت مالکیت روت هستند و بیت setuid اونها هم فعاله. هر سه قبل از اینکه کار مهمی انجام بدن، کاربر رو احراز هویت میکنند.
فک نمیکنم اینجوری باشه ، چون دستوراتی بود که من توی اوبونتو بدون سودو زدن استفاده میکردم ولی در دوان ( دبیان بدون سیستم دی ) باید سودو پشتش بزارم ! پس قطعا راهی وجود داره : )
فکر کنم به خاطر اینه که اون دستورات توی /sbin/ یا /usr/sbin/ قرار دارند و این مسیرها توی PATH شما نیستند و به همین خاطر نمیتونید اونها رو بدون sudo اجرا کنید. مقدار متغیر PATH رو ببینید.
echo $PATH
مدتیه که اکثر توزیعها، /sbin/ رو لینک میکنند به /usr/sbin/.
(این مطلبی را که اینجا بیان می کنم تنها حاصل تجربه شخصی من می باشد.)
همانطور که می دانید در مراحل نصب دبیان ، کاربری را ایجاد می کنیم و من هم در مراحل نصب دبیان کاربری را بنام a ایجاد کرده بودم.
...
دلیل اینکه حتی با ورود به کاربر روت نتونستید adduser رو اجرا کنید این بوده که /sbin/ و /usr/sbin/ توی PATH شما نبودند.
وقتی su رو بدون هیچ آپشنی و آرگومانی اجرا میکنید، به طور پیشفرض شما رو وارد کاربر روت میکنه، متغییرهای محیطی رو هم تغییر نمیده. در نتیجه PATH شما همون PATH قبلی بوده، PATH قبلی هم شامل /usr/sbin/ و /sbin/ نبوده. adduser هم داخل /sbin/ هست.
اینها رو که کنار هم بذارید، متوجه میشید چرا نتونستید adduser رو اجرا کنید.
اگه از su میخواستید که پوسته رو به صورت login shell اجرا کنه، اونوقت adduser هم بدون مشکل پیدا و اجرا میشد.
اینکار با دادن - یا l- یا login-- به su ممکنه. هر سه معادل هم هستند. مثلا su رو به یکی از شکلهای زیر اجرا میکردید:
su -
su -l
su --login
اگه su رو به شکل بالا اجرا کنید، پوسته مثل وقتی باز میشه که از طریق console وارد کاربر روت شدید. دایرکتوری جاری رو هم به هوم روت تغییر میده.
برای اینکه ببینید دقیقا چیکار میکنه، صفحه man اون رو ببینید. این آپشن رو همون اولها توضیح داده.
man su
میتونید از sudo -i و sudo -s هم استفاده کنید. تا جایی که میدونم، sudo -i با su -l فرقی نداره. sudo -s هم مثل sudo -i عمل میکنه با این تفاوت که دایرکتوری جاری رو تغییری نمیده.
وقتی گروه یه کاربر رو عوض میکنید، همون موقع نتیجه رو نمیبینید. کاربر باید از حسابش خارج و دوباره بهش وارد بشه تا تغییرات گروه اعمال بشه.
میشه با اجرای دستور newgrp تغییرات رو توی پوسته فعلی اعمال کرد، بدون اینکه به خروج از حساب و ورود دوباره نیاز بشه. ولی این فقط برای پوسته فعلی جواب میده.
به خاطر همین با اضافه کردن یه کاربر به گروه sudo، همون موقع به نتیجه نرسیدید.
چند تا کاربر دارم ؟
cat /etc/passwd
root:x:0:0::/root:/bin/bash
nobody:x:65534:65534:Nobody:/:/usr/bin/nologin
dbus:x:81:81:System Message Bus:/:/usr/bin/nologin
bin:x:1:1::/:/usr/bin/nologin
daemon:x:2:2::/:/usr/bin/nologin
mail:x:8:12::/var/spool/mail:/usr/bin/nologin
ftp:x:14:11::/srv/ftp:/usr/bin/nologin
http:x:33:33::/srv/http:/usr/bin/nologin
systemd-coredump:x:981:981:systemd Core Dumper:/:/usr/bin/nologin
systemd-network:x:980:980:systemd Network Management:/:/usr/bin/nologin
systemd-oom:x:979:979:systemd Userspace OOM Killer:/:/usr/bin/nologin
systemd-journal-remote:x:978:978:systemd Journal Remote:/:/usr/bin/nologin
systemd-resolve:x:977:977:systemd Resolver:/:/usr/bin/nologin
systemd-timesync:x:976:976:systemd Time Synchronization:/:/usr/bin/nologin
tss:x:975:975:tss user for tpm2:/:/usr/bin/nologin
uuidd:x:68:68::/:/usr/bin/nologin
dhcpcd:x:974:974:dhcpcd privilege separation:/:/usr/bin/nologin
dnsmasq:x:973:973:dnsmasq daemon:/:/usr/bin/nologin
rpc:x:32:32:Rpcbind Daemon:/var/lib/rpcbind:/usr/bin/nologin
avahi:x:972:972:Avahi mDNS/DNS-SD daemon:/:/usr/bin/nologin
colord:x:971:971:Color management daemon:/var/lib/colord:/usr/bin/nologin
gdm:x:120:120:Gnome Display Manager:/var/lib/gdm:/usr/bin/nologin
geoclue:x:970:970:Geoinformation service:/var/lib/geoclue:/usr/bin/nologin
git:x:969:969:git daemon user:/:/usr/bin/git-shell
ntp:x:87:87:Network Time Protocol:/var/lib/ntp:/bin/false
polkitd:x:102:102:PolicyKit daemon:/:/usr/bin/nologin
rtkit:x:133:133:RealtimeKit:/proc:/usr/bin/nologin
usbmux:x:140:140:usbmux user:/:/usr/bin/nologin
g:x:1000:1000:G:/home/g:/bin/zsh
openvpn:x:968:968:OpenVPN:/:/usr/bin/nologin
nm-openvpn:x:967:967:NetworkManager OpenVPN:/:/usr/bin/nologin
libvirt-qemu:x:965:965:Libvirt QEMU user:/:/usr/bin/nologin
flatpak:x:964:964:Flatpak system helper:/:/usr/bin/nologin
qemu:x:963:963:QEMU user:/:/usr/bin/nologin
خیلی از اونها برای سرویسهای پشت زمینه و اینجور چیزها استفاده میشن، سیستمی هستند.
هر کدوم که میبینید پوسته اونها یه پوسته واقعی (مثلا bash یا sh یا zsh یا ...) نیست، سیستمی هست. پوسته توی قسمت آخر مشخص میشه. قسمتها با علامت دو نقطه ":" از هم جدا میشن.
همینطور که میبینید، پوسته تعدادی زیادی از اونها nologin هست که نمیذاره کاربری به اونها وارد بشه. مگه اینکه مستقیم از su استفاده کنید و بگید یه پوسته واقعی مثل bash رو با دسترسی اون کاربر اجرا کنه.
استفاده اون کاربرهای سیستمی این هست که وقتی یه برنامهای که قراره اجرا بشه و به دسترسی روت نیاز نداره و از طرفی دسترسی کم مناسب اونها نیست، با این کاربر سیستمی اجرا بشه که هم دسترسی کمتری از روت داشته باشه و هم بتونه کارهای لازم رو انجام بده. بین کاربرهای سیستمی مختلف و همینطور بقیه اجزای سیستم جداسازی هم انجام میشه.