/sys/class/backlight/acpi_video0/brightness(udev?) へのユーザーアクセスをプログラムで提供する方法

/sys/class/backlight/acpi_video0/brightnesssudoデスクトップの起動時に最後のバックライト設定を増減、設定、検索、復元する簡単なスクリプトを提供するスクリプト（via）を介してバックライトを制御します。xrandrNvidiaインターフェイスはsysfsデバイスを介して実装されているため、オプションではありません。

私は同じタスクを実行するためにスライダーとスピンボックスを提供する簡単なQtインターフェースを作成しましたが、ユーザーがいくつかのインターフェースを使用したりインストールしたりすることなく設定を変更できるように、suプログラムsudoに高い権限を提供する方法について心配しています。 。execvsystem

これは重複ではありませんユーザーによるバックライトの制御（xbacklightなし）。 （これはすでにスクリプトで行ったことです。）

この質問はプログラミング方法の質問に近いです（SOの場合は少し一般的です）。私が理解していないのは、次のことを行う方が良いかどうかです。

1. ユーザーが明るさを変更できるように権限を変更するudevルールを作成し、元の権限を復元する2番目のルールを作成しますか？ （しかし、プログラム内でルールを実行する方法は？）
2. フルデスクトップセッションのユーザー権限を変更するudevルールを作成します（許可 - 優先されていませんが、ユーザーが起動時にではなくログインしたときにルールをトリガーする方法は何ですか？）
3. まだ見つからないコードで別の特権昇格を使用していますか？

単純で一般的な解決策が必要なようですが、udevドキュメントを見た後にsysfsファイルの権限（または所有者またはグループ）を変更して復元するルールは単純ですが、プログラムでどのように変更をトリガしますか？開始後終了時に元の権限を復元しますか？

/sys/class/backlight/acpi_video0/brightness私が好むのは、書き込み直前に変更が行われたがすぐに復元されない限り、sysfsデバイスが変更されないようにプログラム内で変更を処理することです。

私はudevの専門家ではありません。基本的には、マニュアルページと1/2ダースチュートリアルウィキペディアページ。そのようにして、私はC / C ++でルールをトリガするプログラムを見つけられませんでした（またはそれを見たときには認識しませんでした）。だからudevが解決策を提供するかどうかはわかりませんが、ファイル権限の観点から見ると、プログラム自体に対する権限を高める安全な方法を見つけるよりも優れた研究領域のようです。

それではudevが存在するのでしょうか？それでは、コードでトリガーする方法は何ですか？それとも、デスクトップセッション全体でsysfsファイルの権限を変更することに満足していますか？ - それでは、ブートではなくデスクトップブート時にこれをトリガーする方法は？

udevでない場合は、sysfsファイルに直接書き込むことができるように一時的な権限昇格を達成するための安全な方法はありますか？

最悪のシナリオでは、単にexecvorを使用してsystemスクリプトを呼び出してsudo処理することができますが、各ユーザーに対して構成し、orのメンバーになることなく、すべてのユーザーに対して処理できるよりエレガントな方法を探しています。グループ/etc/sudoers。wheelsudo