OS X: Armazenando dados do MySQL com segurança, em uma imagem criptografada do FileVault usando um link temporário

0

Estou tentando fazer com que um MySQL instalado no macports use um diretório de dados armazenado dentro do diretório home protegido por FileVault.

Eu usei sudo cp -a /opt/local/var/db/mysql5 ~/db/ (o -a para garantir que as permissões permanecessem intactas) e substituí o diretório mysql5 original por um link: sudo ln -s ~/db/mysql5 /opt/local/var/db/mysql5

No entanto, quando eu agora tento iniciar o MySQL, ele falha. Segue o link soft pelo menos até o ponto em que ele modifica alguns arquivos no ~/db/mysql5 dir, notavelmente o log de erros que é anexado a ele:

110108 15:33:08 mysqld_safe Starting mysqld daemon with databases from /opt/local/var/db/mysql5
110108 15:33:08 [Warning] '--skip-locking' is deprecated and will be removed in a future release. Please use '--skip-external-locking' instead.
110108 15:33:08 [Warning] '--log_slow_queries' is deprecated and will be removed in a future release. Please use ''--slow_query_log'/'--slow_query_log_file'' instead.
110108 15:33:08 [Warning] '--default-character-set' is deprecated and will be removed in a future release. Please use '--character-set-server' instead.
110108 15:33:08 [Warning] Setting lower_case_table_names=2 because file system for /opt/local/var/db/mysql5/ is case insensitive
110108 15:33:08 [Note] Plugin 'FEDERATED' is disabled.
110108 15:33:08 [Note] Plugin 'ndbcluster' is disabled.
/opt/local/libexec/mysqld: Table 'mysql.plugin' doesn't exist
110108 15:33:08 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it.
110108 15:33:09  InnoDB: Started; log sequence number 4 1596664332
110108 15:33:09 [ERROR] /opt/local/libexec/mysqld: Can't create/write to file '/opt/local/var/db/mysql5/mac.local.pid' (Errcode: 13)
110108 15:33:09 [ERROR] Can't start server: can't create PID file: Permission denied
110108 15:33:09 mysqld_safe mysqld from pid file /opt/local/var/db/mysql5/gPod.local.pid ended

Não consigo ver porque o MySQL não pode criar o arquivo pid , já que criá-lo manualmente usando o _mysql user ( sudo -u _mysql touch mac.local.pid de dentro de ~/db/mysql5 )

Alguma idéia de como resolver isso?

    
por GJ. 08.01.2011 / 18:46

4 respostas

1

Tait Lewis explicou muito bem o problema com a permissão de execução. No entanto, fazer isso para uma conta de usuário real é um risco de segurança e pode impedir a execução legítima de outros membros do grupo staff .

A maneira como resolvi o mesmo problema foi a seguinte:

  • Crie uma nova conta de usuário padrão (para este exemplo, chamamos de db ) com o FileVault habilitado para ela. Use uma senha pelo menos tão strong quanto a do seu usuário principal.
  • Enquanto estiver conectado como seu usuário principal, execute os seguintes comandos:
  • monte a imagem FileVault do usuário db, sem torná-la navegável no Finder:

sudo hdiutil attach /Users/db/db.sparsebundle -owners on -mountpoint /Users/db -nobrowse

  • Corrija as permissões para que o usuário _mysql possa executar o diretório inicial do usuário do db:

sudo chown :_mysql /Users/db; sudo chmod g=x /Users/db

  • Desligamento do MySQL:

sudo /opt/local/etc/LaunchDaemons/org.macports.mysql5/mysql5.wrapper stop

  • Copie os arquivos MySQL para o FileVault:

sudo cp -a /opt/local/var/db/mysql5 /Users/db/ (NÃO adicione / após mysql5 )

  • Agora, você exclui, exclui com segurança ou renomeia o diretório /opt/local/var/db/mysql5 .

  • Em seguida, crie o link suave:

sudo ln -s /Users/db/mysql5 /opt/local/var/db/mysql5

  • Finalmente, inicie o MySQL novamente:

sudo /opt/local/etc/LaunchDaemons/org.macports.mysql5/mysql5.wrapper start

Note que toda vez que você reiniciar o Mac, você precisará montar a imagem (com o comando sudo hdiutil ... ) e iniciar o MySQL manualmente, pois ele falhará ao ser montado quando o launchd tentar iniciá-lo automaticamente antes que a imagem seja montada.

    
por 15.01.2011 / 00:38
2

Comentei uma de suas perguntas semelhantes, pois acho que há uma maneira melhor de armazena dados MySQL em um estado criptografado .

Isso soa como um problema de permissão. Na sua pasta pessoal, o FileVault define permissões para rwx------ (ou seja, o proprietário pode ler, gravar e executar, mas o grupo e outros usuários não têm permissões), em comparação com o padrão rwxr-xr-x de uma pasta típica.

O fator em jogo aqui é que permissões de execução permitem que um usuário pesquise (a) passeie pela pasta . Então, quando o usuário _mysql invoca mysqld e segue o symlink, ele engasga tentando percorrer sua pasta pessoal. É mysqld_safe que grava as mensagens de erro no log, usando as permissões do usuário que o invocou (provavelmente root se mysqld_safe for iniciado usando o script de inicialização do MacPorts, sudo /path/to/mysqld_safe ou similar).

Você pode testar essa hipótese executando os seguintes comandos em sequência:

$ cd ~/db/mysql5/
$ sudo -u _mysql touch mac.local.pid

deve ser bem-sucedido porque não há travessia envolvida e

$ sudo -u _mysql touch ~/db/mysql5/mac.local.pid
$ sudo -u _mysql touch /Users/[username]/db/mysql5/mac.local.pid

deve falhar, mas

$ sudo -u _mysql touch ../mac.local.pid

provavelmente será bem-sucedido, pois ~/db/ provavelmente tem as permissões de pasta padrão mais brandas mencionadas anteriormente.

Uma solução simples seria definir o grupo em sua pasta pessoal como _mysql e conceder às permissões do grupo a pesquisa na sua pasta pessoal:

$ sudo chown :_mysql ~
$ chmod g=x ~

mas isso tem graves ramificações de segurança . Qualquer pessoa que atue como o usuário _mysql (potencialmente através de uma vulnerabilidade no MySQL) pode navegar em sua pasta pessoal e manipular arquivos e pastas de acordo com suas permissões, por padrão rwxr-xr-x para pastas e rw-r--r-- para arquivos. Como vimos anteriormente, isso inclui ~/db/ e quaisquer pastas ou arquivos criados pelo usuário, bem como ~/Public/ e ~/Sites/ . Mesmo que um invasor não consiga obter diretamente uma lista de arquivos em sua pasta pessoal, há muitos arquivos comuns para ler e muitas maneiras de usá-los para coletar dados sobre o que mais está contido. ( .bash_history vem à mente.)

    
por 12.01.2011 / 23:45
0
Primeiro, se você ainda não fez isso, certifique-se de verificar se sua versão do MySQL suportará links simbólicos para a (s) tabela (s) em questão. De acordo com este artigo de 2008 , links simbólicos só eram suportados para tabelas MyISAM naquela época e "Para arquivos usados por tabelas para outros mecanismos de armazenamento, você pode ter problemas estranhos se você tentar usar links simbólicos."

Assim que estiver convencido de que sua versão do MySQL deve suportar o que você está fazendo, verifique qual usuário você está tentando iniciar mysqld_safe as e compare isso com as permissões em /opt/local/var/db/mysql5/ . Como você usou cp -a , é provável que o diretório seja de propriedade e gravável pelo usuário _mysql (é por isso que funciona quando você sudo -u _mysql touch... ), mas você está tendo falhas ao tentar iniciar o MySQL com sua conta de usuário normal ( que não é _mysql e, portanto, não teria acesso de gravação ao diretório).

    
por 11.01.2011 / 10:48
0

Isso pode ser improvável, mas se você estiver criando links para uma partição separada, poderá sempre montar essa partição no ponto de link flexível e, em seguida, fazer um link flexível onde normalmente seria montada.

    
por 12.01.2011 / 06:05