setuid, или временно перестать быть рутом и обратно

вернуть не получится. Можешь форкнуть процесс, в одном сделать setuid на простого пользователя, и когда нужно сделать что-то от рута скомандовать второму процессу.

>Естественно ради безопасности, всю большую работу можно выполнять под простым пользователем, но когда потребуется доступ к sysfs, вернуть себе на время права рута. Когда доступ завершён, нужно вновь стать пользователем.

Нельзя сделать две программы ? Одна c SUID а вторая пусть делает всю работу от пользователя и когда нужно запускает SUID-ую

В смысле весь код работы с sysfs вынести в отдельную программу и на нее поставить suid.

установить CAP_DAC_OVERRIDE
(man 7 capabilities)

socketpair, потом fork.

Потом какая-нибудь ветка теряет UID и они общаются через сокет.

Сделаю наверно через fork+pipe, так будет проще всего.

Через socket тоже можно общаться с помощью read/write

зачем сокеты и прочие IPC?
используем CAP_DAC_OVERRIDE 
или более функциональный CAP_SETUID

> зачем

для переносимости?

>> зачем

>для переносимости?

Какая нафик переносимость при работе с sysfs ?

> при работе с sysfs ?

да, это я не учел:)

Обычно открывают нужные файлы рутом, а потом делают setuid, но это если заранее известно куда писать.

а sys_write() права не проверяет, да? ;)

> а sys_write() права не проверяет, да? ;)

обычный write не проверяет.

уже проверил, спасибо
тогда, это в принципе лучший вариант

> уже проверил, спасибо тогда, это в принципе лучший вариант

запуститься от рута, открыть файл и сбросить права скажем до демона? оно конечно вариант, но AFAIU автор хочет что-то делать с sysfs -> не факт, что подойдёт бо скорее всего, доступ к sysfs нужен будет не в начале исполнения программы но где-то там, далеко и глубоко -> всё время сидеть под рутом и ждать, когда же он понадобиться не есть гут. впрочем, это лишь моё предположение. нужна конкретика.

// wbr