---
# System prepended metadata

title: Logbook 4

---

<h1>Logbook 4</h1>

### Tarefa 1

>Nesta tarefa, percebemos que o *printenv* permite-nos ler a variável de ambiente que pretendermos. Enquanto isso, o *export* permite-nos criar uma nova variável ou modificar o seu valor e o *unset* permite-nos apagar uma variável já existente.

```
//Leitura de uma variável [por exemplo, PWD] usando o printenv
[11/12/21]seed@VM:~/.../Environment_Variable_and_SetUID$ printenv PWD
/home/seed/Downloads/seed-labs-master/category-software/Environment_Variable_and_SetUID

//Apagar uma variável ambiente usando unset
[11/12/21]seed@VM:~/.../Environment_Variable_and_SetUID$ unset PWD
[11/12/21]seed@VM:~/.../Environment_Variable_and_SetUID$ printenv PWD



```

### Tarefa 2
>Depois de correr o programa duas vezes (uma com *printenv()* no processo Pai e outra com *printenv()* no processo Filho).
>Através da utilização do comando *diff* entre os outputs das duas execuções conseguimos verificar que não existem diferenças entre os dois casos .
>Concluimos assim que como o processo filho herda uma cópia do ambiente do Pai tem acesso a todas a todas a variáveis de ambiente a quais o procesos Pai tem acesso.

### Tarefa 3

>Ao correr o programa 'myenv.c' com o seguinte comando:
```
execve("/usr/bin/env", argv, NULL);
```
> Obtemos retorno vazio. No entanto, ao substituir o comando por:
```
execve("/usr/bin/env", argv, environ);
```
>Obtemos uma lista de variáveis de ambiente. Assim , como apenas substituimos o terceiro argumento '*NULL*' por '*environ*' , é intuitivo concluir que o novo processo , criado por *execve* obtém as suas variáveis de ambiente através do terceiro argumento de execução do programa.

### Tarefa 4

> Para comprovar que o comando *system* herda as variáveis ambiente do processo que o chama, decidimos executar o código fornecido e comparar os resultados obtidos com os resultados da segunda tarefa. Ao comparar, com o *diff*, os ficheiros parecem diferentes. No entanto, ao comprovar com um comparador de textos da Web, descobrimos que ambos têm o mesmo conteúdo, apenas em ordem diferente.

### Tarefa 5

> Depois de fazer todos os passos, reparamos que as variáveis de ambiente modificadas num utilizador normal não afetam as variáveis de ambiente de outro utilizador já que estas são ao nível de utilizador. Como exemplo, modificamos a variável PATH de um dos utilizadores, o que afetou a data do sistema e impediu que eu pudesse exercer qualquer função nesse utilizador. Quando trocamos de utilizador, o erro não persistia e podemos exercer o enunciado onde deu o PATH de costume.

### Tarefa 6

>Após fazer o pedido nesta atividade, reparamos que o programa Set-UI executou a função '*ls*' no local atual, mostrando todos os ficheiros locais.

```
./sys
cap_leak.c myenv.c catall.c myprivenv.c print.c sys sys.c
```
Como sabemos que este programa tem acessos de privilégio, podemos considerar que ao colocarmos código maliciosos dentro do ficheiro *sys.c*, este seria executado a nível de root, mesmo se o utilizador não deter tais permissões.

