Pada awalnya saya mencoba melacak kembali beberapa xtermke xtermpid berdasarkan info yang saya temukan di /proc/lockstetapi itu longgar. Maksud saya, itu berhasil, saya pikir, tetapi itu adalah keadaan terbaik - saya tidak sepenuhnya memahami semua informasi yang disediakan oleh file dan hanya mencocokkan apa yang tampaknya sesuai antara kontennya dan proses terminal yang dikenal.
Kemudian saya mencoba menonton lsof/stracepada write/talkproses aktif antara ptys. Saya belum pernah benar-benar menggunakan salah satu program sebelumnya, tetapi mereka tampaknya mengandalkan utmp. Jika pty saya yang ditargetkan tidak memiliki utmpentri untuk alasan apa pun mereka berdua menolak untuk mengakui bahwa itu ada. Mungkin ada jalan keluar, tetapi saya cukup bingung untuk meninggalkannya.
Saya mencoba beberapa udevadmpenemuan dengan 136 dan 128 node perangkat nomor utama seperti yang diiklankan untuk masing pts- ptmmasing /proc/tty/drivers, tetapi saya juga tidak memiliki pengalaman yang sangat berguna dengan alat itu dan sekali lagi muncul tidak ada yang substansial. Menariknya, saya perhatikan :minkisaran untuk kedua jenis perangkat ini sangat mengejutkan 0-1048575.
Baru setelah saya meninjau kembali kernel kernel ini saya mulai berpikir tentang masalah dalam hal mounts. Saya telah membaca itu beberapa kali sebelumnya, tetapi ketika penelitian lanjutan di baris itu membawa saya ke tambalan 2012 ini/dev/pts saya punya ide:
sudo fuser -v /dev/ptmx
Saya pikir apa yang biasanya saya gunakan untuk mengaitkan proses dengan mount? Dan tentu saja:
USER PID ACCESS COMMAND
/dev/ptmx: root 410 F.... kmscon
mikeserv 710 F.... terminology
Maka dengan informasi itu saya bisa lakukan, misalnya dari terminology:
sudo sh -c '${cmd:=grep rchar /proc/410/io} && printf 1 >/dev/pts/0 && $cmd'
###OUTPUT###
rchar: 667991010
rchar: 667991011
Seperti yang Anda lihat, dengan sedikit pengujian eksplisit, proses semacam itu dapat dilakukan untuk menghasilkan proses master pty yang sewenang-wenang. Mengenai soket, saya cukup yakin orang bisa mendekatinya dari arah itu juga menggunakan socatsebagai lawan debugger, tapi saya belum meluruskan bagaimana. Namun, saya curiga ssmungkin membantu jika Anda lebih terbiasa dengan saya daripada saya:
sudo sh -c 'ss -oep | grep "$(printf "pid=%s\n" $(fuser /dev/ptmx))"'
Jadi saya mengaturnya dengan pengujian yang sedikit lebih eksplisit, sebenarnya:
sudo sh <<\CMD
chkio() {
read io io <$1
dd bs=1 count=$$ </dev/zero >$2 2>/dev/null
return $((($(read io io <$1; echo $io)-io)!=$$))
}
for pts in /dev/pts/[0-9]* ; do
for ptm in $(fuser /dev/ptmx 2>/dev/null)
do chkio /proc/$ptm/io $pts && break
done && set -- "$@" "$ptm owns $pts"
done
printf %s\\n "$@"
CMD
Ini mencetak $$num \0null byte untuk setiap pty dan memeriksa setiap proses master terhadap cek sebelumnya. Jika perbedaannya $$maka ia menghubungkan pid dengan pty. Ini kebanyakan berhasil. Maksud saya, bagi saya, ia kembali:
410 owns /dev/pts/0
410 owns /dev/pts/1
710 owns /dev/pts/2
Yang benar, tetapi, jelas, itu sedikit bersemangat. Maksud saya, jika salah satu dari mereka membaca dalam banyak data pada saat itu mungkin akan hilang. Saya mencoba mencari cara untuk mengubah sttymode pada pty lain untuk mengirim bit berhenti dulu atau sesuatu seperti itu sehingga saya bisa memperbaikinya.
sudo find /proc/*/fd/0 -ls | grep '/dev/pts/4', akan memberikan daftar PID (/proc/PID) sebagai output.