Defina um prazo para um processo ou aplicativo
Com um pequeno script em segundo plano, você pode definir um prazo para um processo ou aplicativo.
Desde que o usuário não saiba a senha do administrador , ela não será superada com muita facilidade.
A solução abaixo
É um script de plano de fundo tão pequeno. Limita o uso por dia a um número definido de minutos, a ser definido no cabeçalho do script. Uma vez configurado (o que não é muito difícil), ele é executado com muita facilidade e nenhuma ação adicional é necessária posteriormente.
O script
#!/usr/bin/python3
import subprocess
import os
import sys
import time
#--- set the time limit below (minutes)
minutes = 1
#--- set the process name to limit below
app = "gedit"
uselog = "/opt/limit/uselog"
datefile = "/opt/limit/currdate"
def read(f):
try:
return int(open(f).read().strip())
except FileNotFoundError:
pass
currday1 = read(datefile)
while True:
time.sleep(10)
currday2 = int(time.strftime("%d"))
# check if the day has changed, to reset the used quantum
if currday1 != currday2:
open(datefile, "wt").write(str(currday2))
try:
os.remove(uselog)
except FileNotFoundError:
pass
try:
# if the pid of the targeted process exists, add a "tick" to the used quantum
pid = subprocess.check_output(["pgrep", app]).decode("utf-8").strip()
n = read(uselog)
n = n + 1 if n != None else 0
# when time exceeds the permitted amount, kill the process
if n > minutes*6:
subprocess.Popen(["kill", pid])
open(uselog, "wt").write(str(n))
except subprocess.CalledProcessError:
pass
currday1 = currday2
Como usar
- Na área de trabalho (ou em qualquer outro lugar), crie uma pasta chamada:
limit
- Copie o script em um arquivo vazio, salve-o como
limit_use
(sem extensão) dentro da pasta e torne-o executável
Edite no cabeçalho do script o nome do processo a limitar e o número máximo de minutos permitidos. No exemplo:
#--- set the time limit below (minutes)
minutes = 1
#--- set the process name to limit below
app = "gedit"
Copie a pasta para o diretório /opt
:
cp -r /path/to/limit /opt
Agora edite /etc/rc.local
para fazer o script executá-lo como root
na inicialização:
sudo -i gedit /etc/rc.local
Pouco antes da linha
exit 0
outra linha:
/opt/limit/limit_use &
É isso aí
Quando alguém tenta matar o script em segundo plano:
(ação não permitida)
Explicação; como funciona
- Uma vez a cada 10 segundos, o script verifica se o processo de destino está em execução. Nesse caso, "adiciona" um "ponto" a um uso total, para ser gravado em um arquivo (
/opt/limit/uselog
). Se o limite diário for atingido, o script não permitirá mais a execução do processo, eliminando-o, se existir.
- Na mudança do dia (a data é registrada em um arquivo, portanto, a reinicialização não ajudará), o arquivo de log é excluído, permitindo que uma nova quantidade de tempo de uso seja acumulada.
- Como o script é executado na inicialização ,
rc.local
somente usuários com privilégios de sudo podem parar o script, mesmo assim, apenas se o usuário souber o nome do processo.
Pare o script
Caso você queira interromper o script, use o comando:
sudo kill "$(pgrep limit_use)"
Mas, novamente, você precisaria da senha do sudo para fazer isso.
EDITAR
Embora o script acima deva fornecer uma maneira razoavelmente segura de limitar o uso de um aplicativo, conforme mencionado pelo @Bytecommander, ele pode ser superado, embora não com muita facilidade. A combinação com a medida abaixo tornará muito improvável que isso aconteça, a menos que seu filho conheça a configuração e tenha bastante experiência com Linux / Ubuntu.
Medida adicional
Um pouco mais longe de uma "solução simples", mas ainda não muito difícil de configurar, é a medida adicional abaixo. Se nosso suspeito delinquente descobrir que o script é chamado /etc/rc.local
, conseguir tornar-se root e remover a linha /etc/rc.local
, ou conseguir parar o script dessa maneira, podemos enfrentá-lo com o próximo problema: a tela escurece após Além disso, a solução verifica se o script em segundo plano está em execução após 5 minutos após a reinicialização, ocultando se não estiver.
A medida extra é uma verificação de inicialização, se a linha /opt/limit/limit_use &
está presente /etc/rc.local
, e uma verificação após 5 minutos, se o script ainda estiver em execução. Como o script é executado a partir de um iniciador (oculto nos aplicativos de inicialização) /etc/xdg/autostart
, será bastante difícil descobrir o que está acontecendo, a menos que você saiba como isso é feito. A combinação dessas duas medidas torna improvável que seu filho descubra, e se o fizer, provavelmente nada o impedirá.
Como configurar
Duas etapas simples estão envolvidas:
Copie o código abaixo em um arquivo vazio e salve-o blackout.desktop
na área de trabalho:
[Desktop Entry]
Name=not allowed
Exec=/bin/bash -c "sleep 15 && /usr/local/bin/blackout.py"
Type=Application
Terminal=false
NoDisplay=true
Copie o arquivo para /etc/xdg/autostart
:
sudo cp /path/to/blackout.desktop /etc/xdg/autostart
Copie o script abaixo em um arquivo vazio, salve-o blackout.py
na área de trabalho, torne-o executável e copie-o para /usr/local/bin
:
cp /path/to/blackout.py /usr/local/bin
O script
#!/usr/bin/env python3
import subprocess
import time
def dim_screen():
screen = [
l.split()[0] for l in subprocess.check_output(["xrandr"]).decode("utf-8").splitlines()\
if " connected" in l
]
for scr in screen:
subprocess.Popen(["xrandr", "--output", scr, "--brightness", "0"])
if not "/opt/limit/limit_use &" in open("/etc/rc.local").read():
dim_screen()
time.sleep(300)
try:
pid = subprocess.check_output(["pgrep", "limit_use"]).decode("utf-8").strip()
except subprocess.CalledProcessError:
dim_screen()
Explicação
Os lançadores /etc/xdg/autostart
iniciam um aplicativo (neste caso, a verificação de segurança extra) para todos os usuários. Isso pode ser substituído localmente, mas você deve saber que a verificação é executada. Ao colocar a linha NoDisplay=true
em nosso iniciador, ele não aparecerá localmente Startup Applications
; portanto, sem saber que ele existe, é improvável que seja descoberto.
Além disso, seu filho tem apenas 15 segundos para descobrir (a tela fica apagada); portanto, ele teria um problema sério, a menos que seja um gênio, tenha muita experiência com o Ubuntu e uma mente criativa.