すでに実行されているXセッションで2番目のXサーバーを起動したいと思います。
Debian 8より前は、この行を編集してに/etc/X11/Xwrapper.config変更することができました。これにより、権限のないユーザーとしてX内でXを実行できました。 XはXorgのsetuidラッパーです。allowed_users=consoleallowed_users=anybody
Debian 9 では状況が変わりました。 Xはもはやsetuidラッパーではなく、代わりにXに必要な権限はsystemdによって制御されます。ファイルは/etc/X11/Xwrapper.configもう存在しません。
パッケージを使用してレガシー動作を復元できますxserver-xorg-legacy。次の/etc/X11/Xwrapper.config行を含める必要があります
allowed_users=anybody
needs_root_rights=yes
もう1つの可能性はtty1 ... tty6のいずれかに切り替えてXを実行することですxinit xterm -- :1 vt1が、vt1 ... vt6はtty1 ... tty6に準拠する必要があります。 （tty8 ... tty12 / vt8 ... vt12は使用できなくなりました。）
以前の設定を使用せずにコンソールに切り替えることを避けたいです。私は検索可能性が欲しいですxinit xterm -- :1 vt8。
権限のないユーザーがすでに実行されているXで2番目のXサーバーを起動できるようにsystemdをどのように設定しますか？
ベストアンサー1
xinit攻撃に対して非常に脆弱なので、使用しないことをお勧めします。。代わりに使用してくださいstartx。 xinit警告や文書なしですべてのユーザーIDのX接続を許可するように作成されたようです。 startx問題を解決しているようです。私はこれがなぜ受け入れられるのか、最初にこのようなことが起こったのかどうかわかりません。
rootユーザーとして：
systemd-run --property PAMName=login \
--property User=my-user \
--property StandardInput=tty \
--property TTYPath=/dev/tty8 \
sh -c 'chvt 8 && startx /usr/bin/xterm -- :1'
魔法はPAMName=PAMセッションを定義して開き、特定のTTYに関連付けることです。これは得るpam_systemdあなたが欲しいものをしてください。私はだまされましたlogin。技術的には特別な処理が必要な場合に備えて新しいPAM「サービス名」を定義する必要がありますが。
したがって、必要なコマンドを実行するスクリプトを作成できます。次に、許可を使用してrootとしてスクリプトを実行しますsudo。
SELinuxを使用している場合は、この問題も克服する必要があります。