Tworzenie plików i katalogów z określonym właścicielem (użytkownikiem / grupą) podczas sudo

Potrzebuję wgetczegoś (powoduje skompresowanie pliku w cwd), następnie muszę go wyodrębnić, a następnie wykonać kilka operacji kopiowania / przenoszenia / modyfikacji i być może w końcu wykonanie skryptu (z pobranego archiwum).

Teraz wszystkie te zadania, bezpośrednio ( wgetwyodrębnij itp.) Lub pośrednio (uruchamiając skrypt), powodują tworzenie plików i katalogów (wszystkie w bieżącym katalogu roboczym). Robię to wszystko jako root(nie ma możliwości, aby zrobić to z końcowym, pożądanym użytkownikiem).

Problem polega na tym, że wszystko, co powstało w tym procesie, jest własnością użytkownika root lub użytkownika sudo. Kiedy skończę (a czasem w połowie), muszę wydać szereg poleceń chmodi chown, aby wszystko naprawić.

Byłoby miło, gdyby w jakiś sposób mógł powiedzieć systemowi, że „Odtąd wszelkie pliki lub katalogi, które utworzysz, gdy wydam polecenia jako root, tworzysz z takimi i takimi prawami własności i uprawnieniami”.

Zawsze możesz, sudo -u username touch filenamegdy skrypt jest wykonywany jako root. Zwykle nie wymaga hasła, w zależności od sudoerskonfiguracji.

Alternatywnie, uruchom su username -c touch filename. Dodatkowe argumenty są dostarczane do powłoki użytkownika, a -copcja powłoki wykonuje określone polecenia zgodnie z konwencją.

Niektóre polecenia (jak mkdir) obsługują argumenty w celu określenia uprawnień:

mkdir -m 0700 foo

Domyślnie operacje na plikach są zgodne z umaskzestawem powłoki. Określa, które uprawnienia są odrzucane . umaskOd 0022na przykład robi nie ustawić uprawnienia zapisu dla grupy i innych. Ustaw, aby 0077uniemożliwić grupie i innym osobom uzyskanie jakichkolwiek uprawnień.

Możesz ustawić setgidw katalogach, aby wszystkie pliki tworzone w obrębie dziedziczyły członkostwo w grupie:

chmod g+s someDir

Niektóre uniksy obsługują to samo zachowanie dla setuid( chmod u+s), ale nie dla Linuksa.

Jest inny sposób, jak sądzę, dość elegancki. Korzystanie z instalacji (1)

Na przykład zabbix-agentd potrzebuje podfolderu wewnątrz / var / run, ale ostatnie dystrybucje używają tmpfs dla / var / run, więc katalog nie przetrwa ponownego uruchomienia. Rozwiązałem go, tworząc plik / etc / sysconfig / zabbix-agentd zawierający:

install -g zabbix -o zabbix -d /var/run/zabbix

W systemach uniksowych nowo utworzone pliki i katalogi są własnością właściciela procesu, który je utworzył. Standardowe narzędzia zwykle nie mają opcji zmiany właściciela utworzonych plików.

Zmienne z UID i GID pierwotnego użytkownika

Jeśli kilkakrotnie uruchamiasz niektóre polecenia, możesz użyć zmiennych $SUDO_UIDi $SUDO_GIDodnieść się do użytkownika, który wywołał sudo:

sudo sh -c "do_something ; chown -R \"\$SUDO_UID:\$SUDO_GID\" files and directories"

Automatyczne pobieranie listy utworzonych plików i katalogów

Jeśli chcesz automatycznie uzyskać listę utworzonych (i ewentualnie zmodyfikowanych) plików i katalogów, możesz uruchamiać swoje polecenia pod stracenadzorem opartym na ptrace()wywołaniu systemowym:

strace -qqfe open,creat,mkdir,link,symlink,mknod -o '|your_processing_of_strace_output' do_something

lub możesz użyć na przykład Installwatch, który jest oparty na LD_PRELOADmechanizmie.

Pomysły na dalszą pracę

W oparciu o metody wspomniane powyżej możliwe jest stworzenie narzędzia, które automatycznie zmienia właściciela i ewentualnie prawa dostępu do utworzonych / zmodyfikowanych plików. Użycie może być tak proste, jak:

sudo watch-chown do_something