-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jaboatão dos Guararapes, PE, 24 de setembro de 2014. Assunto: GnuPG (versão 2.0.26) - Configurações - Parte IV (emit-version) Percebi que o comportamento do aplicativo GnuPG mudou com a instalação da versão 2.0.26. Antes, com a versão 2.0.22, a informação de versão era colocada automaticamente, por padrão, na assinatura emitida no modo 'armor', conforme o exemplo abaixo: - -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJUC7pbAAoJECrgJcAIqGGAIEcH/i7N272Biy8QCmPYfxhnCDN6 K3TyMLMhUp6TrmrQdN5AQ+ULr0rVAk/87u9wwc9Cc8fF8FLr+OA6klje5+7SqqLj mBPTHWRpHTO+3Ixae1yGj4VEeCySjg0JSkEtN6tZ7lFZDk5pEtURZSn919XPWepK 9AHoYab8VJ7xv6amL7j+mVf6OmTbYXcx8Ik3AAdzsVP0BVh2InG3zky2+j99AWOo ewZ6lU3lttpNs+4i/kXMnmMslFVIGHE2CCU6SN9receozBzaFnl+ITz4XfFjLCgC hUL6HB1I/VuaNl7imifpFljadNFVCxCA+KhkJ8lhiQQhmYjFV435wo2aPIEyLeI= =4bGK - -----END PGP SIGNATURE----- - -------------- Agora, com a versão 2.0.26 do software, a saída _padrão_ é semelhante a esta: - -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJUIw2uAAoJECrgJcAIqGGAhUQIAIMje8l/43l4jcHz56L79bNo GwttwnvHlQrC6Y73TWb+gvy3R216XE12CiVYLgaUH8F+TVimn5X255cnDfjYJH0a TEAojjds0He4L2G6rHbRpATPBod/cjFeJaYwRdeZlaW2keIVx/4zC/CljGSMq2Qe 2jt1ifbM8pgFaonQNDCXh/YnwftpjCmt0KyZgCUPm8PIuv3WqUeTFi8FrjMaUwMW MxgRtXgk9gPR6Cgmy/HWV83bRKFEnz9GMIRRh43dowEk3ctTGbi+W50MlPZDeKk1 hi76uXvTECGG9B66H9G/bVxoDknlsS38PB9rj8wB/pisyN5AOCsERSPlxNTf3iM= =4yCB - -----END PGP SIGNATURE----- - -------------- Pergunta: Como obter a informação de versão completa como antes? Resposta: com a opção de configuração (emit-version) incluída no arquivo de configuração do GnuPG (por padrão ~/.gnupg/gpg.conf). Obs.: curiosamente, é obrigatório que se coloque a opção 'emit-version' _três vezes_ no arquivo de configuração para se ter a informação de versão efetivamente _completa_. - -------------- Se colocar apenas _duas_, então a saída se parecerá com isto (retirou a informação de Sistema Operacional): - -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.26 iQEcBAEBCAAGBQJUIw/4AAoJECrgJcAIqGGAzVgH/Azxn7Nz3A6qRhlnM8wEIWLd RGR0mbfcn4tSnyZdtAJDKPV6mYnd+ZhlkLws27BL3nUqkd7afoqF9D3lHSABCQxF VM+X12Ot8zeqAf1zHLWnjTZYDU2p55qMJPMVTrTblP3/MzKboGcOEqDQsABsZNaJ y6y88GyE8kHZbcyRHdiSNTunfDkjLl4vZPvs0gBTLTJrw44/TQiwC7qWAjMr7TQE S+yOiqREo9jr7rvD/E9R64meuW2h7KIOYG6G6LU1ZyMXjTF7H/N4AJb96RTEEv1o 0wV2DphYuhIJ7cxIeI56deSniGsC8v3wxdy+AzCBXb+ZEiU0z+lAv2Es22ZdHAU= =N3nc - -----END PGP SIGNATURE----- - -------------- Se colocar apenas _uma_, então a saída se parecerá com isto (retirou a informação de versão chamada 'número menor'): - -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQEcBAEBCAAGBQJUIxCPAAoJECrgJcAIqGGA28oH/2EPQQ3GNy8J+PVbLhy8smZU RGHSymuSN8FMo5M5pj9VodRJePDckvQto9dE4KjHCSvFsL2/GHE5Pp1Jrbuolmqx 7hS6FZnTIUj8PexoUSckgQ6ZkRvSYpC8qAhYr0QT1s5hLknROKrGEh3Yrc6IiRZJ vxVJ7WV1IFqVCfngValJWjh3MYbfLzyxtqZREkkj2hJG6DFHprqQEnoCjZBjacab osrMwuPTn2qVC8jMn/J/IxLc8fZgm5mXN6C3sMm78qm5o37tVMM518ddyrvJIw9c sh57sVMdQhyTXM/55uZdhdBEKDaKYbA73fybLajgO/NgZ6utJgrCfZ+LnSzU4no= =pTvI - -----END PGP SIGNATURE----- - -------------- Informando-se _três_ vezes a opção 'emit-version', a saída da assinatura no modo 'armor' voltará a ser _completa_: - -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.26 (GNU/Linux) iQEcBAEBCAAGBQJUIxEbAAoJECrgJcAIqGGAjBMH/3fRVUgT5PVN8BT7Q2kwmXXm 24c9kuIAG5PrbNOEnczcK1+xMG1Wa4U0tS7xdiO2WbxJz3drkUxRw5ckQx92OrT/ +DRNwpYYiqaO6qw3C/cjLdQVcr/YK+c+WYYq2wqQ6r9qIzjDd98Vhiw1T5a/43y/ Cd8AAfm0XUy1OtNMzr0J+xgCGXi8GG7BFNnoYEdmax0qr8UyuQkojXqZq+E0npnn Y9vbkz5JPUaTUl5gVk2SSy5J/dHWl7AielgblsqVqV+oMB15PeYm9tc0FmYr81zA imh0ksipq9m/x1IlaiY3amgrJhEJvk921JHV73yKbxqxX75wplGn/QF4OJLfjWo= =7ErL - -----END PGP SIGNATURE----- - -------------- Agora, você decide qual 'layout' mais te agrada (eu ainda prefiro a informação _completa_, como antes). Jamenson Ferreira Espindula de Almeida Melo Usuário Linux nº 166197 https://linuxcounter.net/cert/166197.png Impressão digital da chave: 234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.26 (GNU/Linux) iQEcBAEBCAAGBQJUIxTaAAoJECrgJcAIqGGAxWQH/if65aDpsKue/k3v/v0lio0x w4gpnq9hPp1xfesAkwjZ6V3GwVOm0keKfbup/0Nt4TJFREbt9/W8MRjHqtoRWPJL JcKZIMusVbe8VqggoLpaoIdKn6RHpONCKy2h5WsJDtNGV7yeuMxgI8kyta8/0N5/ u9rWJZq/Yz9az9+KjQJBjGV4X0PIwTzR1EJ5snq85Ksc7Utu1lFP5nM4yVhatnnS 5Q3pSBi/EjmKikHrcRwIDppimf+SzeMarPEAgpStLucXZHdY9iHGy8wThXaegpqL sZkBJx/aU/mAoSeX1VBZrBpvokcxOwO5999Uk/xTDDjXPDGchYU/M3L2Lx5bXRQ= =pKjE -----END PGP SIGNATURE-----
quarta-feira, 24 de setembro de 2014
GnuPG (versão 2.0.26) - Configurações - Parte IV (emit-version)
Minha Chave Pública (formato OpenPGP)
-----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQENBFOWq5sBCACooPQ0WA48y8taHmTuW0YE0nxm+s9dHpv8nDiNXvt8jSI8GcDj ha3WqxU7Gn/8WSsK6uMzyIDFiQ1jzFJwQelSN0+yg32vx+aCXWjizJk4ShKHGmFE rrsG1dOsgfEJrFv+3tURchRO87utHq8WAjFp/n3Xq1YTEqdrShvJJwtOl9hOejDM mYTtvxHYVRgOnEuY71sTL/gbYfM9R9ym5AWtZO1+f1zQC6QZKgpAsUt3vakxbslL 0WzHi1T2q2ep9EYd8kGHrJGYZmU4+EfRcyPTQ+Cnhbc7IzDZX3vzQkz88cIugsfb tbancEGmwwjyi616EMOsrKlq+CK4/7GldTd5ABEBAAG0ZUphbWVuc29uIEZlcnJl aXJhIEVzcGluZHVsYSBkZSBBbG1laWRhIE1lbG8gKEFkdm9nYWRvLiBSZWNpZmUs IFBlcm5hbWJ1Y28sIEJyYXNpbCkgPGphZmVzcEBnbWFpbC5jb20+iQFBBBMBAgAr AhsDBQkDw65MAh4BAheAAhkBBQJT/iXpBgsJCAcDAgYVCAIJCgsEFgIDAQAKCRAq 4CXACKhhgLNcB/4oYjI9a+D0kBqpM2tFOltwRSk5urK3pmX3Y/ImM2Cry6GiEVwA G4oXBIPbJPLxdRSX4syAfMz86D4R3EHIIPTE+ygVbm9Ce8GZp7+aWB8ZXz095Uhg fquFIqSJdE+LdcuNEK8KRTuP+qtD14O0aHa/nH7QiFLpQrpeBPjHJ/TFhbzdJKwH A9ML1FqXfxzSPv8uCkfz0Qk+wjTappcG++2gjvHljZONYFfvh7DCGw+6iMv45/ov 3UCIGv7Q3Kvz3kPAuO4cJZm0Sf4fyVxoUJ/JaC+MxmIgT9yiuR/g0Rt32+uI4F3d rDgEfFUL6ejNW7F3ZoppkTwYic9z5UdepDXjiQEiBBABAgAMBQJT/jB9BQMAEnUA AAoJEJcQuJvKV618HDYH/jIDgM6S3IbZbpwfpNzh8c6KCTFLqqMBmlmLUAM8cFVh SXM9XV+O8cj2+AViDyObg1e6qbziK4jyZsSfDN9Rom8lMnY3CtbG0hqWWPoeTnFB QA6tRhWAEPnG8olX3jYGBSENh7PFoJBEPaOSvT6MEKqbNxnKkrnT6tjK70NglVPk P6vOhcj3gN/I+eY2UxL80H6eZ/KKP7329X2bvneHi+LCNdY5TLo614UGCDmCq/fp 86eI1lgC7OuF8+tX8QySdGzG2BzcAeyvPGKjE2gpkS1Ut2VcmP/niE3ZjMUE9uDb swxGXC+769wXf8jpP3bJKXhqK6cEeqKDHNQ+KfD7PXvR0UrRSAEQAAEBAAAAAAAA AAAAAAAA/9j/4AAQSkZJRgABAQEAyADIAAD//gATQ3JlYXRlZCB3aXRoIEdJTVD/ 2wBDABALDA4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQERXRTc4 UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVGC8aGi9jQjhCY2NjY2NjY2Nj Y2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2P/wgARCADM AJ8DAREAAhEBAxEB/8QAGgAAAgMBAQAAAAAAAAAAAAAAAgMAAQQFBv/EABcBAQEB AQAAAAAAAAAAAAAAAAABAgP/2gAMAwEAAhADEAAAAe2QhCFAJiMokM0mw0LZCEIQ sohCk5RyBBRCywzedoesIQshRAU4BzQSFllglhGg9AaVhZCFJRwTmEBLGABlEGSj Y49GNWyESjlHDKglMMsXYyUy4tUWVZpPRrZCIJ5YRLol1zWodS0zJstKCUIxi0wb x6Q1LCJmPLGvOujnb6bYyw6hRUCBKELOPrn1K6qwiYjzJ0Mb6M0ymWNsslSKBBlC FHG3z6Z1i1iZzyg/OuznbabYywiqkUUDKuVCcbWOrZ1yLEA8oa8b2NOsfYQZdQGF gCpbjm3PQ1npkWkyTfEZ150MrKCV0unUdZQjNylWNLMlz0bNKuso5nPrztY3RWdZ 9TFrPYztkadQRWbm1MNzsx01M49Z1TZrv3yiYMdcKahi0MsuhzYWFZdlSiSM6Mbd c6tYiY89M8WaaOyAyomjsIodc2UKlWltPuH2RETWHO7R6t1LRWdKV2oaJzXahoKq yXYa6tYMtBXNnWQbnTtQhU1izTpiAuzWWWBC4lzppllkSijBmrzt9sBsAKKW7GDA YWmjWXVZCFJRllx406aliVl02y4AJl5QpnduGWQiUQUcvG2Z02hVbRWRakfcmiyr noakLIRIUUcXOpnTxilQwQdRFQpD3npVZCESAnOOLnT819ah9rLILhUZ4qXndcem HkIYUxHLEEl6HPpVjrHBS3QIEoS0c3ry1nZNqmnjEFRAIdLn1dmqs0SnEqilIw6x m6cxDHnVPPgFFEN2N9DGwUxpYJRE5m8Z94ohYQtFrRCGrOutjocojAkFbQK5e+eb WRLS1sWgLZRB8vZx0dLJSshIuhTjbxm1kQktaP/EACUQAAIBAwMFAQEBAQAAAAAA AAABAgMQEQQSIBMhIjEyMEEUM//aAAgBAQABBQLk5KJPVQQ9ZI/1VBauZHVkK0Jf rV1ZOo5PPDIpFLUyiU6sai/BvCr6hzG7K/vhCbg6NVVFz1Go38f5gXrHe9OeyVOa muOsqYVsG0URowRWUoPds7yhtMDRp6mypwZWnvmkRp5FRFRTOlElp4n+dkKKinTN iQ4I6XedPsaeW6leu9tJlKO4UbLm7Mn9aJ9r6r/g/dB3X4y9S96P3ess0mUftCsv wn6f1o/d36msSoRwOSRGojcjPFyR1IjqK1ZeejXjd1e+ox1YfLg2dJHgRYpWbGyW BRps6aI9iv7oeFJTy7SRXXlFdpdiMHMSkbDGCLJDRUpZpwpN1EnForoj8xV5fVWP mjGTYYMWiO2DBttUWYx9QvU+5WV2NkRifBj9FO9RErK8xkR2VmMZgisK7pHpp3l3 Uk2U5NE5PENwrOyjuajjlVWJIQ2ZttNouxkV6frlWXZCtKSTVU6h1DeR7iHaPzym sxEIlBM2o8TxZsRGCVmLu/wnJOSYmbsLCa2IUEYMjZkozj1OeqrqMKcjdgjIQrtj ZKVt/nSqKpC8tVTRU1pKpKYzPkjBGZ1TqnUOoOQkVHiMfVGs6coauDIyUrZtntan 3VkbUbTF6/qPoyQqOLhrLS4UrNC4srH84vhSfeJgS4sre/5+MPqPNlf7fH//xAAd EQABBQADAQAAAAAAAAAAAAABABARIDACEkBg/9oACAEDAQE/AfnIUZwopFYRGA8g 8g8g1NetoUPFSoUU5MEWFTYuFyeaGs0LhFDcuGFAx17IUDxaUTpKnwwuq6rquqI0 HkFp2HkDRaFCOYpDQ/LMY8sxjyzCGBt//8QAHREAAgMBAQADAAAAAAAAAAAAAREQ IDAAQCFQYP/aAAgBAgEBPwH9Q5VVIwPkPkPkOoq6/PPnLqIdBIgiBxoaCguKqRQ4 DESYNDA1XGhh87LlY2XLU1fPnz+hNFy5VGJ8hwcDM4jM4jM4jM4i3//EACYQAAED AwMDBQEAAAAAAAAAAAEAICERMDECEBJAQXEiMlBRkWH/2gAIAQEABj8CdJoolYAX uXZTpWbtNH6pL6ZCizUqgjTaqF/bHEYuAhVDuIsy0fTiWTbDNR2m8QzV0Gpmrx0G ppCrtlZdlZYWQqjbKkqNSy2SvcwfaowbnkqcZUNMShUR4UY2qoaLx6mvS5dmngqV CzX4AXQ8hmNu28XCdOG4dx72KaTJRFvkPtDUGZr4XoFFJqyFO+doZCmoUGvSVC9Q /Pjhf//EACYQAAICAgIDAAIBBQAAAAAAAAABESEQMUFRIGFxgZEwobHB0fH/2gAI AQEAAT8h8l0q+ilv/QwqY72QPT9Cky2/An/UzTxfTr+RuFLFKf2iXOb9lyWaNE+8 Gxehkwe+V1/CtzIS5Hkno7GM4kQgQ7EDRaF1sM6eu15twrHL/wBY3Y0RUCXJFjsJ sUCV2RMzhm1IT2/jry76e/g2QISpk7SNx/QSlaFqhO0okKhOQEse1MXg0IY1udYG fiObukQXBcEzmBi4f4LCGiW0LWQ4nRt6Qu6VmmSPlKH4PTbgez4gpKBLBeDygWmJ YZ0qfgk4C+BCwXkxjww8uPV68ID7G47ilgovBGWhkm8CNMns/t/BZZHrBtEOStm1 Y6E3gIJkkjYltB9AkbJlSiGfZA3t+FlQrsmbktro1DGQoQaR/wCUh1LGnJAPY3VN TP8AI4ttiOhrGSL2uBeA9HKuydnMECoZoShpqlxJCcVurKRCfQgRAxIqUjklIyxQ 3MCHM/RiSpK10NelEDTyugxtepFsZKDlCxcM1KsicHMgRCxLuEl/M0+i0emLZqRj TIujiFh5nNGreZ16CfsTHE8NRREYIwIeV4HQ9Ciy1JM+g7F1iTwoL4bQBHFhrv7I FDb2ZVZM5g51+Vx2MPhiO/AEGlDHsTz3HWDm2bcKeoIckOBqOnplGMcix5nfgmMU GEwk9CK1AjQkJnCNGSwwsK7F/By0cq1lYpKBg6BBDgsLM6/CvNuCJ1109Itb9wzD rTHJRKysNCdSxPJ0NSRyMbXT8NO3yGw19THsu+hnyxQQshunIjCRcjlppfSvB/Bo xzVDmZPG4m1lynoo0b+xNK09YuPVj4iRjjBEMjyh9SIdIiuB7FSGFHExWJQNMVEf nwa8pjitEZqLDQkaDWLfEkkkyWeeTUNByRAQQQR4bOOM85ZWHsShYQxDEGGmeMf/ 2gAMAwEAAgADAAAAENsln233lltlsm1pIlutslt+BDTaE9kl/wCm0msqp5J9ny9V B6XJJtYjpOceaNJu2ksCO3ltZ+u2NRu3+vp/8xNRZ7VNpt8Ytge8Ndr3ZxI784Td pWL8EqsSOmJ4gZTNi67zJr4f6FRo0w7mLS4xs+e25zBFL5iCnjJ9syEuGnFBLfp9 uV2pcZJ9kaRMWIEbJtsCudx53JLvssWUtpzJL7Zm2ofXltNrKh0oELjLdJK/iQAP xLLrY4qR52pPL7E4FGvNbNb/xAAgEQACAgMBAAIDAAAAAAAAAAAAARARICEwMUBB UFFh/9oACAEDAQE/EOFlll9r4X+VoocJFQdChrghWKGoe4KLinEQUPNQx8THxYxc LcPgxrifFZvA1TFFCSKDglYkGpcEzG6VwhMTYkJZdeFOxtbLsaEJj2JMS/YxiG1L WhPBF0f0aLFBeDLLWB6HpS+pnKEhiGsfs+h5fdD8xJJQ1gvSxu8PA2Gg2hqxUNDl mjLMkKKLLhYsscMeaFDFcpgGIUPkUJlmzY2N3DHyJiZ6WXCxwxvjuNVCeFlwkP3G y5bYlYxUuLCoNSHF5obUUUUGkUKjxjeT/ALBxfCI9DS8Ge8v/8QAHxEBAQEBAAMB AQADAAAAAAAAAQARECAhMDFAQVFg/9oACAECAQE/EP8Aid+mw2xxbZYbYfhszV/I HjMtbJOEvcvguEeb0+Ij4PD4gjzSbYfgI+K+bNu829zNRRly1atjOxxoQHqcst7X q/0WZL1xkAWjL3EWw99TrIE/LOPCe4LJHxA7+omOtvDD1nme/MD4Pzh4PGb/ABw8 GjLYesYxOoWLbee0fALeZ0zxPgeFsdDB6R5s8JhLS04HT4ieb4HM4vB8v7zI8GbY /PiNJhtttYZbEuw1j4sPDW1temPg8M/xxPc/g/iTzPN//8QAKBABAAICAQMEAgID AQAAAAAAAQARITFBUWFxECCBkaGxwfAw0eHx/9oACAEBAAE/EPV9LlSN1VTEL9Qj MecHCCjYPUwgK8Xp9RCGDl/if9ylCXvoP+M2QA5YOC3pfoiLrErisrl3Mb2bZaL6 5mjQmsVSUaof0uB8EZd/4QUBWrRGzgaBvvf9SwVmVLUsxUUZrEqJdLAJWjUzP4mU AgLTxFalz27wRSA3/k7e82UAZVjo6vmzqw9oTFuOI5lxqIJTswvwEsFOYZZyQSHL qPXohUltxEwBKZrbp56werZnkuj7WUrINv8ASIwFOLX8Rs1EAC7zcdAvlihTV1M6 zULRbAjWF77f9m/nV+YxhVUz74xLuJcV0fZ5/UQgnssXoR8aLwriKi7hS6OUFqMG txSxeA4YG7DUtxeGB1O48PBDFMu+84mATU6idek3EU5hwMnTcI++QG+pn7kXUx7N JBh84/mUReoeEBUxKijiHEoQqpQxizF9DkvWAkmyUCBuKXpQd9P6IetBq8DvuQWO hAvyjv1xD0YkfUBV6gd0xjsD+fZ3Jq+oNu04ocxNHWJi4KlGVKjFdYh6FyEDaoMK BgbEwH8oejO9BUxw/qGCvmHiUuyBlgmgR8wrwktN+nIhhlmjHlmmN4iKH4RNwIwj JQC/zET4f1/2HoxqBW1hcVjARHLk/H5m1oor6lrIt+pSK0fEFVrdUWj4eNG0xBEE sjRHKmDbK2tOggBrpMy9sp3nQZo/mAm1WOy+vxUGqhejfpul9YXSC7tROsMcqgPx EVGeIEjZXOHDEZdDybfzqojgAXlvmmOrz8xxhtBzLzI4LqaOclB8hAs2VUK6Y3Gq V8JdEbClpTKD9woIyC9pWuxuEYo+IrB8zp87lAuGhoZwBeyIZmBbliAzHeENLxAA SbWNRhxArsuIoqUo2Z+pehg1xK8T0MdfQZf74mMu7JiJVgFSo6iwodwIYhhms59F QVFiEUPOIJhgEF9e+jKkluD4lILdGZCWVMEvrKajuUKJGFYQFLK25cWI8TKrVcMa 0/creW3z6gESx2QcTOirfuBfbska6lxLouMgNMv6shQiJ8NMfCpcuJvI7oK+pinM vEWI7jo4UYxCoqx7GMpQYF/NzMSw3KGri2DLAvUTRZHFowQW1B60z4SPMZAF+VYH sYy4vKvv/wAjpmFlZoyuycQIweWDBUe4xpwPKw92DfSJG6XYv016pUO1w9j6MZsW eTMIWOPaAWM3ufPIDMy5TyQrsFdoiyfiL/qJmVHaGWNFpMuWUXyqCgPaxjNzhg8N NP3Mu9TIZjLVqCqG43dofMgcAQoBtcS5biNxsnV1aeazD3ALWjqxXeu13WcaeIfF OEGgu7g44I4oG9kwgYIckYONEu1AWWeZsGHMTlSpxWpUUUq7yHsxf9I5qIA9D2/W v3G/d7sPHSKR+jpBaAA/LGdtIgTM4RHrFsIiYrdbRBz3KlqkXlC8sz0K9WYU5SiX zvEJtYIrL+0ZlPyhZQ+TP4nd6iuXFNjq+J+4GIq4ImadoQdaqLpKxHmwsKHyRNIX gJjzZ4l/A81AtAglrxQ0NxRJAIRyKRIQobP4f9zPTEVB0l41FlmJrqEzSxjUNCVI g8So9MBDJOLwR03WD1mSwrDvqWXFRW9I4m+YYEzb9yKxMazUgql0I2xUK1iCxlQk vHzDKGFgwNzWIwmoZ+5tGsVKD4YVIRlAzPj0AXMAEAGNhwFxYzm5wsCCf//ZiQE+ BBMBCgAoAhsDBQkDw65MAh4BAheABQJT/iXwBgsJCAcDAgYVCAIJCgsEFgIDAQAK CRAq4CXACKhhgFgKCACQlazypR23xa8UBChVGRoVtqj4YMNZQEbbkX2JwAxSOCaU 6CiPXNgCgkXUL5YKcK0dhtELHt36NRwTEgizmSj5L+Zu9PKXDVA1HjbzRIA0uIYn icnVawkOwLxhVybS/lb4GrOdvkf/verHZPAVwVftYgMEi0/X/3OFSHJsTvaaVoKZ s8P2eKZzeT/aFHqcq8vHmi3tqB5amjMg+sxrWOMp5/SxX8VbNNnjouiEwerkf9K6 RoIMXeufewhUnXyW78uLQif8s8qRC79xkp6yiYNXwpIjFHXtAHpqF6AoGCXnmE25 Q7fbee2QllVwwznan1n2mxTpnMYjiWJuOn5PM1xKtGhKYW1lbnNvbiBGZXJyZWly YSBFc3BpbmR1bGEgZGUgQWxtZWlkYSBNZWxvIChBZHZvZ2Fkby4gUmVjaWZlLCBQ ZXJuYW1idWNvLCBCcmFzaWwpIDxqYW1lbnNvbkBib2wuY29tLmJyPokBPgQTAQIA KAIbAwUJA8OuTAIeAQIXgAUCU/4l8AYLCQgHAwIGFQgCCQoLBBYCAwEACgkQKuAl wAioYYB8Ywf/VmTmfdtnzNNcnyJvv39nQUxL3E8YEjxDdrGoZBCyLFNbp/wQMcoH 4cG14IDWDvEzyJUWfkiVTc+pbiHrj5Fd+pWSTowJd54wcPN32vlKMixbAcr54fIN o/pD0hhlOO+CI9mMo2qLhLT6HNMGhMM5cTTDT5QKI0+1zosb7Oh3uzPXz7q2WBeo Dt/dQk2r+kxmp9v26vKm2Z5VSXYPuA0p9xo73BWxUinCJ0YaRdTitB/wdJmCHosj p8/XTV6W4sFFQIBF4nWq6QwCYTaBaD419NOd/tZ7XatIaQJ/pn/G7PUZnL9u78CV EcMa5PQSAy79bPJAlR54rumeyildYZFAjYkBIgQQAQIADAUCU/4wfQUDABJ1AAAK CRCXELibyletfGvJB/4i6N4GdmzQTfkHYV+RisDwTy55jNRTbB5V/3w5Bja/rPNY eKKeiVO24AhHzBk4My7ZAKce+/kn8mcupEkoqL9kDRRFcDvZq/l0e7G2TsUtNyuZ inyQM/1vs7tliCA+fImS6W4kwBxFGrsyG/IdGk6fnKQycJBfFrL9wcACPpowTkI1 wXOIAkfGm9WFJ+1f12t3vu0B5yUxw0Qpody3DL8AyzCXik88cqr7yGRtnIQoJZqo bvoQE5EFe2FAHbU97Y1o3RRdq+2GAoJd3DJ5NHbWD7WIyth0AuRNy6qHFffjMlnu j0nEee+DdEsOg5+xj4msPJe3n8VXT6agFPzbbyHStHJKYW1lbnNvbiBGZXJyZWly YSBFc3BpbmR1bGEgZGUgQWxtZWlkYSBNZWxvIChBZHZvZ2Fkby4gUmVjaWZlLCBQ ZXJuYW1idWNvLCBCcmFzaWwpIDxqYW1lbnNvbmVzcGluZHVsYUBob3RtYWlsLmNv bT6JAT4EEwECACgCGwMFCQPDrkwCHgECF4AFAlP+JfAGCwkIBwMCBhUIAgkKCwQW AgMBAAoJECrgJcAIqGGAfc8H/Rp1XXHhDAZkH56EqjDaCG1ndC0Scz8i3/L/qojL EhPZ6rKEVw3kB/bthk6mHtFSm/KWJjQjpnlx5QhbcsyJU5ywNiBGe0QNWxQJ0ynT zGlibbyKcoEJuK/uYULPf8/hcLhoARtwqxKzwLfJdIbksiaedDom80zwt7j7sFuw XkA4Aogq73s0+lTx3a+GlBbUFbOnfYBeSk4TynUKupHJ0tY+X12Nsvr/GQ6h4bvP rWJGJ/+L0w3sZWykEROna0tpya66X4a9/ylLn2xBkfEwfDGKI7rfoDHRzakN2LpS l1q/Bio9ORfI/UaYGHo3PUYmxq7tdgd1n1y6XFZhz0kWHc6JASIEEAECAAwFAlP+ MH0FAwASdQAACgkQlxC4m8pXrXy4jQf/TnPTC5Lri2SHLg0q/RxL7HIxc0hA8B/K 9YdZFwnA9RwnlOPQGU9d67od4vSiZ1UHefysu15TkLOXZpBZCyaKwrXWXvG4J1DD TVrxqqZ9JFbcWxHME+ExD2paHK3s/bTXl7S9x0SZ/nVFSgN/5/wV4Ur8jK+hqWRC onQV91KoQnINJP9meh9uH5DsKKLA9aTAUpQuye3zi1CN2/7Y1s2E3k3N9GqwdbJn 0lw3klghVoZcQQ+nTZdxDNx6zOve7TiFYKk7Nop/Xt40aD6Dagzez/WYe5cz8UA0 YeZDFtj12bJf70BPtmMYIqj4vNaEg8vbZ/xCSUvn3siW4MZIew6TYbkBDQRTlqub AQgAtbDZqSvE6JWq2MVJ3gAABENinpmfe6tLyoC+YDLbAUSFb/MkU1YbODesPX1O PxHV9r3SCc+BNrO9O1B4QeUFtOsho3EB/jfbdwUaorEyWCONzfzbCQOVgqNdta+R KXsDxNWKxEomZprhua7EqixGV1b4D/A/0cPf10zPtsv+d7vzGNKXf3NDo6PQJwtY bbDw50hQzWTdGNUL3wbDmMlNixqsID1VkXnaEb6S++s3QSB9tUiO9GFCNJ1l+Ubk RWD7n5ewmN0F3gQu+S7C6edqdat5U0eIS8NdEGm7bsN8u2IwdpMPCqM01zOB64FT QGuwyrWyzWBBJ1BBLYw8/M9wCwARAQABiQElBBgBAgAPAhsMBQJTmBBfBQkDw8uy AAoJECrgJcAIqGGA1M0IAISE2wjMq6r0qFHDOQi+fKbLz7v1N7v6A1g0s6vYGzYE QArv7SX+08pKyUTZ4q4IPyIh0CxpxW7yMvNIICaa0fy6Q0cvS/8xzmQ9L87zjddA sIv2DcxCJbh+CKFJX6Dvo/3RXlhDbNo+intrhqj1ll5Ug5ZysvsniJIict/iEZgk ousIkxjntblaS3XZDTCvrVigePiUnFzWD3UnWqWibepgEBecTsPTs1gk/J+jKzMo T6cnfXWv/pLD3DGczQtGxOLjb7P0KL74Wd2KhtKe9m8G17s1zvKG78paNieGXN/B EaD2V9S0KGtuV4RVz4ZgBz8RSk4d3qE/NKtOYz5DJpI= =zY2T -----END PGP PUBLIC KEY BLOCK-----
terça-feira, 16 de setembro de 2014
GnuPG - Configurações - Parte III (no-greeting)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jaboatão dos Guararapes, PE, 16 de setembro de 2014.
Assunto: GnuPG - Configurações - Parte III
Quando se executa um comando como <gpg --edit-key usuário> entra-se no
ambiente para edição dos atributos par de chaves do usuário informado.
Logo na entrada do ambiente, é exibida uma informação de direitos
autorais. Tem gente que _não_ gosta da exibição de tal mensagem.
Então, a opção <no-greeting>, quando presente e _habilitada_ no arquivo
de configuração do GnuPG (em regra, ~/.gnupg/gpg.conf), faz com que tal
mensagem _não_ seja exibida.
Para _não_ exibir a informação sobre direitos autorais:
no-greeting
Antes, _sem_ a opção no-greeting ...
______________
jamenson@lfs-comp01: ~/Documentos $ gpg --edit-key jamenson
gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Chave secreta disponível.
pub 2048R/0x2AE025C008A86180 created: 2014-06-10 expires: 2016-06-10 usage: SC
trust: ultimate validity: ultimate
sub 2048R/0x7ED08E2C60833F3C created: 2014-06-10 expires: 2016-06-10 usage: E
[ultimate] (1). Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jafesp@gmail.com>
[ultimate] (2) [jpeg image of size 4599]
[ultimate] (3) Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamenson@bol.com.br>
[ultimate] (4) Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamensonespindula@hotmail.com>
gpg>
______________
Após, _com_ a opção no-greeting ...
______________
jamenson@lfs-comp01: ~/Documentos $ gpg --edit-key jamenson
Chave secreta disponível.
pub 2048R/0x2AE025C008A86180 created: 2014-06-10 expires: 2016-06-10 usage: SC
trust: ultimate validity: ultimate
sub 2048R/0x7ED08E2C60833F3C created: 2014-06-10 expires: 2016-06-10 usage: E
[ultimate] (1). Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jafesp@gmail.com>
[ultimate] (2) [jpeg image of size 4599]
[ultimate] (3) Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamenson@bol.com.br>
[ultimate] (4) Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamensonespindula@hotmail.com>
gpg>
______________
Agora, você decide qual das duas configurações mais te agrada (eu gosto da primeira!).
Importante:
Versões testadas:
GnuPG v1.4.12 (GNU/Linux) --> Debian Wheezy
GnuPG v2.0.22 (GNU/Linux) --> Linux From Scratch 7.5
Jamenson Ferreira Espindula de Almeida Melo
Usuário Linux nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJUGA3nAAoJECrgJcAIqGGArCkH/27/CJjJceEOfFbLUdj20OZz
0xqWUjtJ7hYCwiDPYWRYQU9iDpV2Y/Pyrapf11heyyK81tm1/PvQCMEt2WcST3ja
1XvhWIV7E0Ey7wzpZqbdEYyRUm27WNAEjdT8mQop6mnBCCuyZebl3K065zdEqEF9
Zk5dMjQW86HdcXQyK0IjdDslbfomtua1EtrS+0nOxbG8F8BnoqdCbu8gCgZM3q6e
unQluetrdwQpVT1EAnsx+NppdauZ9P28yWvwQONIXsA0awlDL+9Y9r4sFgqJ6GR7
iyRpOHERQqK1G+cKJi+tG1Cf8G7eqnjZKkL6wqugzQQlgIpd/xeULjJWN8rMoLQ=
=k4z2
-----END PGP SIGNATURE-----
quarta-feira, 10 de setembro de 2014
Assunto: GnuPG - Configurações - Parte II (keyid-format)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jaboatão dos Guararapes, PE, 10 de setembro de 2014.
Assunto: GnuPG - Configurações - Parte II (keyid-format)
Resumo: série de postagens acerca de configurações do aplicativo GnuPG
em seu arquivo de configuração (por padrão, ~/.gnupg/gpg.conf):
Observe abaixo a saída do comando [gpg --list-key 08A86180]:
pub 2048R/0x2AE025C008A86180 2014-06-10 [expires: 2016-06-10]
Key fingerprint = 234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jafesp@gmail.com>
uid [ultimate] [jpeg image of size 4599]
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamenson@bol.com.br>
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamensonespindula@hotmail.com>
sub 2048R/0x7ED08E2C60833F3C 2014-06-10 [expires: 2016-06-10]
A informação 0x2AE025C008A86180 é a chamada "Identidade da Chave" ("key ID").
Para que a Identidade da Chave seja exibida no formato mostrado acima,
coloque a seguinte linha no arquivo de configuração (por padrão, ~/.gnupg/gpg.conf):
keyid-format 0xlong
_______________________________
Sem a opção em foco (ou com ela configurada para "short"), a saída do
comando [gpg --list-key 08A86180] se parece com isto:
pub 2048R/08A86180 2014-06-10 [expires: 2016-06-10]
Key fingerprint = 234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jafesp@gmail.com>
uid [ultimate] [jpeg image of size 4599]
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamenson@bol.com.br>
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamensonespindula@hotmail.com>
sub 2048R/60833F3C 2014-06-10 [expires: 2016-06-10]
_______________________________
Abaixo a saída do mesmo comando, agora com a opção configurada para
"0xshort":
pub 2048R/0x08A86180 2014-06-10 [expires: 2016-06-10]
Key fingerprint = 234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jafesp@gmail.com>
uid [ultimate] [jpeg image of size 4599]
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamenson@bol.com.br>
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamensonespindula@hotmail.com>
sub 2048R/0x60833F3C 2014-06-10 [expires: 2016-06-10]
_______________________________
Com a opção setada para "long", a saída do comando muda para isto:
pub 2048R/2AE025C008A86180 2014-06-10 [expires: 2016-06-10]
Key fingerprint = 234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jafesp@gmail.com>
uid [ultimate] [jpeg image of size 4599]
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamenson@bol.com.br>
uid [ultimate] Jamenson Ferreira Espindula de Almeida Melo (Advogado. Recife, Pernambuco, Brasil) <jamensonespindula@hotmail.com>
sub 2048R/7ED08E2C60833F3C 2014-06-10 [expires: 2016-06-10]
_______________________________
Agora, basta você escolher qual dos quatro formatos da informação
"keyid-format" mais te agrada.
Jamenson Ferreira Espindula de Almeida Melo
Usuário Linux nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJUD9DCAAoJECrgJcAIqGGAXKoH+wR68XXErhOO8wNtMNlY7Uej
wdu7LFtdJ2UzcjwlNH7PvWDPNcBUSZK/4QWXnGdip5ok8w0aOVkxeKIJtKIOXsSu
wCYk40ESYOfBIZdMUTRAE69VQwbCP090OVcFgg3FYw+i0KzODQJFjy9dzrJatD34
j6dx0sgUdaD2YWL5uAlanfJtdybvLTax8im/QmC8ZomSMwovtJ9C1zRDBxWwyzkI
+QVCDT6OvU8HfZxAylyJ8/r0nJq2oP7xE+YFh01CIxSXdIY0HG1BRjFIlXvIuT/9
SSV2ZOKaicR8hjf4rU/uenWR9x8H+R7z7dNX2KBAlml5AIWRNKcZYX/kIMRWfuw=
=aNYe
-----END PGP SIGNATURE-----
domingo, 7 de setembro de 2014
O Console Framebuffer (Antonino Daplas)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jaboatão dos Guararapes, PE, 07 de setembro de 2014.
Eis uma tradução livre para a lingua portuguesa falada no Brasil do
texto da autoria de Antonino Daplas "The Framebuffer Console". Tal
texto vem junto com os códigos fontes do kernel Linux, estando o arquivo
localizado sob o diretório Documentation/fb/fbcon.txt
O Console Framebuffer
=====================
O console framebuffer (fbcon), como o nome implica, é um console
de texto sendo executado no topo do dispositivo framebuffer. Tem a
funcionalidade de qualquer driver de console de texto padrão, tal qual o
console VGA, com as características adicionadas que podem ser atribuídas
à natureza gráfica do framebuffer.
Na arquitetura x86, o console framebuffer é opcional, e alguns
até mesmo o tratam como um brinquedo. Para outras arquiteturas, é o
único dispositivo de exibição disponível, texto ou gráfico.
Quais são as características de fbcon? O console framebuffer
suporta altas resoluções, variação de tipos de fontes, rotação de
display, multicabeça primitivo, etc. Teoricamente, fontes
multi-coloridas, blending, aliasing, e qualquer característica feita
disponível pela placa gráfica subjacente também é possível.
A. Configuração
O console framebuffer pode ser habilitado utilizando sua
ferramenta de configuração de kernel favorita. Está sob Device
Drivers->Graphics Support->Support for framebuffer devices->Framebuffer
Console Support. Selecione 'y' para compilar o suporte estaticamente,
ou 'm' para suporte de módulo. O módulo será fbcon.
Para ativar o fbcon, pelo menos um driver framebuffer é exigido,
então escolha um dos numerosos drivers disponíveis. Para sistemas x86,
eles quase universalmente tem placas VGA, de forma que vga16fb e vesafb
sempre estarão disponíveis. Entretanto, a utilização de um driver
específico para o chipset da placa te dará mais velocidade e
características, tais como a habilidade de mudar o modo de vídeo
dinâmicamente.
Para exibir o logotipo do pinguim, escolha qualquer logotipo
disponível em Logo Configuration->Boot up logo.
também, você precisará selecionar pelo menos uma fonte
compilada-internamente, porém se você não fizer nada, a ferramenta de
configuração de kernel selecionará uma para você, usualmente uma fonte
8x16.
TRUQUE: Um relato comum de bug é a habilitação do framebuffer sem
habilitar o console framebuffer. Dependendo do driver, você poderá
obter uma exibição preta ou truncada, porém o sistema ainda inicializa
por completo. Se você estiver com sorte em ter um driver que não
altere o chip gráfico, então você ainda obterá um console VGA.
B. Carregamento
Cenários possíveis:
1. Driver e fbcon são compilados estaticamente
Usualmente, fbcon automaticamente se apossará do seu console.
A notável exceção é vesafb. Ele precisa ser explicitamente
ativado com o parâmetro de opção de inicialização vga=. [Nota
do tradutor: conforme a documentação do GNU GRUB, o parâmetro
"vga=" foi substituído por "resolution="]
2. Driver é compilado estaticamente, fbcon é compilado como um módulo
Dependendo do driver, você obtém ou um console padrão, ou
uma exibição truncada, conforme mencionado acima. Para obter um
console framebuffer, faça um 'modprobe fbcon'.
3. Driver é compilado como um módulo, fbcon é compilado estaticamente
Você obtém seu console padrão. Uma vez que o driver seja
carregado com 'modprobe xxxfb', fbcon automaticamente se
apossa do console com a possível exceção do uso da opção
fbcon=map:n. Veja abaixo.
4. Driver e fbcon são compilados como um módulo.
Você pode carregá-los em qualquer ordem. Uma vez que ambos
estejam carregados, fbcon se apossará do console.
C. Opções de inicialização
O console framebuffer tem várias, largamente desconhecidas,
opções de inicialização que podem modificar-lhe o
comportamento.
1. fbcon=font:<name>
Seleciona a fonte inicial para uso. O valor 'name' pode ser
qualquer das fontes compiladas-internamente: VGA8x16, 7x14,
10x18, VGA8x8, MINI4x6, RomanLarge, SUN8x16, SUN12x22,
ProFont6x11, Acorn8x8, PEARL8x8.
Nota, nem todos os drivers podem lidar com fontes cujo tamanho
não seja divisível por 8, tais como vga16fb.
2. fbcon=scrollback:<value>[k]
O buffer de rolagem é a memória que é utilizada para preservar o
conteúdo da exibição o qual já foi rolado ao passado de sua
visualiação. Isso é acessado utilizando a combinação de teclas
Shift-PageUp. O valor 'value' é qualquer inteiro. O padrão é
32KB. O sufixo 'k' é opcional, e multiplicará o 'value' por
1024.
3. fbcon=map:<0123>
Esta é uma opção interessante. Ela diz qual driver é mapeado
para qual console. O valor '0123' é uma sequência que é
repetida até que o comprimento total seja 64 que é o número
total de consoles disponíveis. No exemplo acima, ela é
expandida para 012301230123... e o mapeamento será:
tty | 1 2 3 4 5 6 7 8 9 ...
fb | 0 1 2 3 0 1 2 3 0 ...
('cat /proc/fb' deveria te dizer o que são os números
fb)
Um efeito colateral que pode ser útil é utilizar um valor de
mapa que exceda o número de drivers fb carregados. Por
exemplo, se apenas um driver estiver disponível, fb0,
adicionar fbcon=map:1 diz a fbcon para não se apossar do
console.
Mais tarde, quando você quiser mapear o console para o
dispositivo framebuffer, você pode utilizar o utilitário
con2fbmap.
4. fbcon=vc:<n1>-<n2>
Essa opção diz ao fbcon para apossar-se apenas de um intervalo
de consoles conforme especificado pelos valores 'n1' e 'n2'.
O restante dos consoles fora do intervalo dado ainda serão
controlados pelo driver de console padrão.
NOTA: Para máquinas x86, o console padrão é o console VGA
o qual tipicamente está localizado na mesma placa de vídeo.
Assim, os consoles que são controlados pelo console VGA serão
truncados.
4. fbcon=rotate:<n>
Essa opção altera o ângulo de orientação da exibição do console.
O valor 'n' aceita o seguinte:
0 - orientação normal (0 graus)
1 - orientação horária (90 graus)
2 - orientação de cabeça para baixo (180 graus)
3 - orientação anti-horária (270 graus)
O ângulo pode ser alterado a qualquer tempo afterwards
'ecoando' os mesmos números para quaisquer um dos 2 atributos
encontrados em
/sys/class/graphics/fbcon
rotate - rotaciona a exibição do console ativo
rotate_all - rotaciona a exibição de todos os consoles
A rotação de console apenas se tornará disponível se o Console
Rotation Support estiver compilado em seu kernel.
NOTA: Isto é puramente rotação de console. Quisquer outras
aplicações que utilizem framebuffer permanecerão em suas
orientações 'normais'. Atualmente, o driver fb subjacente é
totalmente ignorante acerca da rotação de console.
C. Anexando, Desanexando e Descarregando
Antes de ir adiante sobre como anexar, desanexar e descarregar o console
framebuffer, uma ilustração das dependências pode ajudar.
A camada do console, como ocorre com a maioria dos subsistemas, precisa
de um controlador que interaja com o hardware. Assim, em um console
VGA:
console ---> controlador VGA ---> hardware.
Presumindo que o controlador VGA pode ser descarregado, uma pessoa deve
primeiro desvincular o controlador VGA da camada de console antes de
descarregar o controlador. O controlador VGA não pode ser descarregado
se ele estiver ainda vinculado à camada de console. (Veja
Documentation/console/console.txt para mais informação).
Isso é mais complicado no caso do console framebuffer (fbcon), pois
fbcon é uma camada intermediária entre o console e os drivers:
console ---> fbcon ---> controladores fbdev ---> hardware
Os controladores fbdev não podem ser descarregados se eles estiverem
vinculados ao fbcon, e fbcon não pode ser descarregado se ele estiver
vinculado à camada de console.
Assim, para descarregar os controladores fbdev, uma pessoa deve primeiro
desvincular fbcon do console, então desvincular os controladores fbdev
do fbcon. Felizmente, a desvinculação de fbcon da camada de console
automaticamente desvinculará os controladores framebuffer do fbcon.
Assim, não existe necessidade de desvincular explicitamente os
controladores fbdev do fbcon.
Então, como nós desvinculamos fbcon do console? Parte da resposta está
em Documentation/console/console.txt. Para resumir:
Ecôe um valor para o arquivo de vínculo que representa o controlador de
console framebuffer. Assim, presumindo que vtcon1 representa fbcon,
então:
echo 1 > sys/class/vtconsole/vtcon1/bind - anexa o console framebuffer
à camada de console
echo 0 > sys/class/vtconsole/vtcon1/bind - desanexa o console framebuffer
da camada de console
Se fbcon for desanexado da camada de console, seu controlador de
inicialização de console (o qual é usualmente modo de texto VGA)
assumirá o controle. Uns poucos controladores (rivafb e i810fb)
restaurarão o modo de texto VGA para você. Com o resto, antes de
desanexar fbcon, você deve tomar uns poucos passos adicionais para ter
certeza de que seu modo texto VGA está restaurado adequadamente. O
seguinte é um dos vários métodos que você pode fazer:
1. Download ou instale vbetool. Esse utilitário está incluído na
maioria das distribuições atuais, e é usualmente parte da ferramenta de
suspender/restaurar.
2. Na configuração de seu kernel, assegure-se de que
CONFIG_FRAMEBUFFER_CONSOLE está configurado para 'y' or 'm'.
Habilite um ou mais dos seus controladores de framebuffer preferidos.
3. Inicialize no modo texto e como root execute:
vbetool vbestate save > <arquivo estado vga>
O comando acima salva o conteúdo dos registradores do seu
hardware gráfico para <arquivo estado vga>. Você precisa fazer
esse passo apenas uma vez, já que o arquivo de estado pode ser
reutilizado.
4. Se fbcon for compilado como um módulo, carregue fbcon fazendo:
modprobe fbcon
5. Agora, para desanexar fbcon:
vbetool vbestate restore < <arquivo estado vga> && \
echo 0 > /sys/class/vtconsole/vtcon1/bind
6. Isso é tudo, você está de volta ao modo VGA. E se você compilou
fbcon como um módulo, você pode descarregá-lo com 'rmmod fbcon'
7. Para reanexar fbcon:
echo 1 > /sys/class/vtconsole/vtcon1/bind
8. Uma vez que fbcon estiver desvinculado, todos os controladores
registrados no sistema também se tornarão desvinculados. Isso
significa que aquele fbcon e controladores individuais framebuffer podem
ser descarregados ou recarregados à vontade. Recarregar os
controladores ou fbcon automaticamente vinculará o console, fbcon e os
controladores juntos. Descarregar todos os controladores sem
descarregar fbcon tornará impossível para o console vincular fbcon.
Notas para usuários vesafb:
==========================
Infelizmente, se a sua linha de comando de inicialização incluir um
parâmetro vga=xxx que configura o hardware em modo gráfico, tal como
quando carregar vesafb, vgacon não carregará. Em vez disso, vgacon
substituirá o console de inicialização padrão por dummycon, e você não
obteria qualquer display após desanexar fbcon. Sua máquina ainda está
viva, então você pode reanexar vesafb. Entretanto, para reanexar
vesafb, você precisa fazer um dos seguintes:
Variação 1:
a. Antes de desanexar fbcon, faça
vbetool vbemode save > <arquivo estado vesa> # faça uma vez
para cada modo
vesafb,
# o arquivo pode
ser reutilizado
b. Desanexe fbcon como no passo 5.
c. Anexe fbcon
vbetool vbestate restore < <arquivo estado vesa> && \
echo 1 > /sys/class/vtconsole/vtcon1/bind
Variação 2:
a. Antes de desanexar fbcon, faça:
echo <ID> > /sys/class/tty/console/bind
vbetool vbemode get
b. Tome nota do número do modo
b. Desanexe fbcon como no passo 5.
c. Anexe fbcon:
vbetool vbemode set <número do modo> && \
echo 1 > /sys/class/vtconsole/vtcon1/bind
Amostras:
========
aqui estão 2 amostras de scripts bash que você pode utilizar para
vicular ou desvincular o controlador de console framebuffer se você
estiver em uma caixa X86
- - ---------------------------------------------------------------------------
#!/bin/bash
# Desvincula fbcon
# Mude isto para onde seu arquivo vgastate atual estiver localizado
# Ou Utilize VGASTATE=$1 para indicar o arquivo de estado em tempo de execução
VGASTATE=/tmp/vgastate
# caminho para a ferramenta vbe
VBETOOL=/usr/local/bin
for (( i = 0; i < 16; i++))
do
if test -x /sys/class/vtconsole/vtcon$i; then
if [ `cat /sys/class/vtconsole/vtcon$i/name | grep -c "frame buffer"` \
= 1 ]; then
if test -x $VBETOOL/vbetool; then
echo Unbinding vtcon$i
$VBETOOL/vbetool vbestate restore < $VGASTATE
echo 0 > /sys/class/vtconsole/vtcon$i/bind
fi
fi
fi
done
- - ---------------------------------------------------------------------------
#!/bin/bash
# Vincula fbcon
for (( i = 0; i < 16; i++))
do
if test -x /sys/class/vtconsole/vtcon$i; then
if [ `cat /sys/class/vtconsole/vtcon$i/name | grep -c "frame buffer"` \
= 1 ]; then
echo Unbinding vtcon$i
echo 1 > /sys/class/vtconsole/vtcon$i/bind
fi
fi
done
- - ---------------------------------------------------------------------------
- - --
Antonino Daplas <adaplas@pol.net>
Jamenson Ferreira Espindula de Almeida Melo
Usuário Linux nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAEBCAAGBQJUDAZOAAoJECrgJcAIqGGARYEH+wU6XL+cf03EhATGkPBCsUOt
clzKY9qS2OSsnnTCdyv/cBRyZzbF3dzKBYWLDwm0duNhAwPCZ+sx1hCCFw+s8j+b
O6a0ZjhUpOCHukYdKWp9hZ3SRrGfHDWjEimZ9G1BCfbRQ4GQa/PGPCIupN+10aWI
0wpWyD+Fu8gxOdOvBSCZQ9s4nCghNo7XOu9Eif4Td+1gGhy3CXidiY4nwVvf7dKc
ggHANj3FprQQgcYc9E1deGc/j/kIDxUzus4Kx0Xg/lUpigEDP9dJ7s7apgS0tk5B
HXzh0085Lnn9Fv4p/hLbClVoqe1R7IoPkJ3tFeuj7lWXoACuiit/f7SBwzlLTBk=
=X/BN
-----END PGP SIGNATURE-----
sábado, 6 de setembro de 2014
GnuPG - Configurações - Parte I
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jaboatão dos Guararapes, PE, 06 de setembro de 2014. Assunto: GnuPG - Configurações - Parte I Para mudar o chamado "Algoritmo de Dispersão" (Em criptografia, um algoritmo de hashing ou dispersão é um método de cifrar dados de forma a manter a sua integridade - http://pt.wikipedia.org/wiki/Algoritmo_de_dispers%C3%A3o) do GnuPG: personal-digest-preferences sha256 Antes ... - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Depois ... - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Importante: Versões testadas: GnuPG v1.4.12 (GNU/Linux) --> Debian Wheezy GnuPG v2.0.22 (GNU/Linux) --> Linux From Scratch 7.5 Jamenson Ferreira Espindula de Almeida Melo Usuário Linux nº 166197 https://linuxcounter.net/cert/166197.png Impressão digital da chave: 234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJUC7pbAAoJECrgJcAIqGGAIEcH/i7N272Biy8QCmPYfxhnCDN6 K3TyMLMhUp6TrmrQdN5AQ+ULr0rVAk/87u9wwc9Cc8fF8FLr+OA6klje5+7SqqLj mBPTHWRpHTO+3Ixae1yGj4VEeCySjg0JSkEtN6tZ7lFZDk5pEtURZSn919XPWepK 9AHoYab8VJ7xv6amL7j+mVf6OmTbYXcx8Ik3AAdzsVP0BVh2InG3zky2+j99AWOo ewZ6lU3lttpNs+4i/kXMnmMslFVIGHE2CCU6SN9receozBzaFnl+ITz4XfFjLCgC hUL6HB1I/VuaNl7imifpFljadNFVCxCA+KhkJ8lhiQQhmYjFV435wo2aPIEyLeI= =4bGK -----END PGP SIGNATURE-----
terça-feira, 2 de setembro de 2014
Permissões de Arquivos do Unix (Perderabo, 28/05/2005)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jaboatão dos Guararapes, PE, 02 de setembro de 2014.
Aqui está, em tradução livre para a língua portuguesa falada no Brasil, o texto postado por Perderabo "Permissões de Arquivos do Unix".
Unix File Permissions (Perderabo, 28/05/2005 - http://www.unix.com/tips-and-tutorials/19060-unix-file-permissions.html)
Introdução
Eu tenho visto alguma informação errada relativamente às permissões de arquivo do Unix. Eu tentarei esclarecer as coisas. Dá uma olhada neste exemplo de alguma saída do ls:
$ ls -ld /usr/bin /usr/bin/cat
drwxrwxr-x 3 root bin 8704 Sep 23 2004 /usr/bin
- -r-xr-xr-x 1 bin bin 9388 Jul 16 1997 /usr/bin/cat
$
Na primeira linha, aquele "root" diz que o diretório é propriedade do usuário chamado "root". E que "bin" ś o grupo do diretório. Você precisará entender usuários e grupos e eu presumirei que você entende. Meu objetivo é explicar aquelas "drwxrwxr-x" e "-r-xr-xr-x" coisas. Aquele campo é uma combinação do tipo do arquivo e permissão de acesso. Coletivamente, essa informação é algumas vezes chamada de modo do arquivo. E algumas vezes ela é chamada de permissões. Um bom lugar para começar é dando uma rápida olhada em como essa informação é atualmente armazenada no disco. A forma como ela é armazenada afeta um número de decisões que devem ser tomadas ao longo dos anos.
Como o "Modo do Arquivo" é armazenado.
No disco, informação acerca de um arquivo é armazenada em uma estrutura chamada um "inode". Cada arquivo tem o seu próprio inode. Um item de dados em um inode é chamado de "modo" e ele se parece com isto:
|---modo do arquivo---|
| |
|
| |--completo---|
|
|-tipo| | |-básico--|
| | | | |
oo0 000 000 000 000 000
... ... ... ... ... ...
| | | | |
| | | | |---- rwx para outros
| | | |
| | | |-------- rwx para grupo
| | |
| | |------------ rwx para usuário
| |
| |---------------- configura uid, configura gid, sticky bit
|
|---------------------- tipo do arquivo: comum (-)
diretório (d)
carácter especial (c)
bloco especial (b)
fifo (p)
ligação simbólica (l)
socket (s)
Eu entendo que o "modo" realmente significa simplesmente as permissões e que o tipo do arquivo foi enfiado para dentro para economizar espaço. Porém, o autor do aplicativo ls está tratando o modo como um item único. Eis o porque de o tipo do arquivo ser o primeiro carácter da sequência de permissão no saída de "ls -l". O tipo do arquivo usualmente será um dos sete tipos que eu mostrei acima. Algumas versões de Unix adicionarão alguns mais. A única outra coisa a saber a partir do formato é que não existe mais compartimento para adicionar mais bits de permissão.
Representando aquelas permissões em octal
O aplicativo ls pode exibir, digamos, "rwxrwxrwx" para as permissões em um arquivo. Também é muito comum utilizar um número octal para expressar as permissões em um arquivo. E como você vê acima, assim é como elas são armazenadas. Você pode escutar alguém dizer que alguns tem permissões 777. Isso é o mesmo que "rwxrwxrwx" e muito mais fácil de pronunciar. Então você precisa saber como convertê-los. Três dígitos binários ou bits correspondem a um dígito octal:
421
rwx
Assim, o bit de leitura tem valor 4, o bit de escrita tem valor 2, e o bit de execução tem valor 1. Você simplesmente adiciona tais valores para obter um dígito octal. Então, "-rwxrwxrwx" é 777. E "-rwxr-x---" é 750. Se você ainda não consegue ver como ir de "r-x" para 5, talvez esta tabela ajude:
- --- = 0
- --x = 1
- -w- = 2
- -wx = 3
r-- = 4
r-x = 5
rw- = 6
rwx = 7
Perceba que precisamos de 4 dígitos octais para exprimir todos os bits de permissões. Os primeiros três bits são especiais e são frequentemente zero. E você quase sempre aprende primeiro sobre os 9 bits seguintes. Algumas pessoas param aí e nunca aprendem aqueles primeiros três bits. Porém, existem 12 bits de permissão, não apenas 9. Dito isso, vamos agora dar uma olhada nos 9 bits seguintes.
Os Bits de Permissão Básicos
Nós temos 3 triplas: uma tripla para o usuário, uma tripla para o grupo, e uma tripla para outros. Algumas vezes o "usuário" é chamado de proprietário. E algumas vezes "outros" é chamado de "mundo" Eu utilizarei "usuário" e "outros" pois o comando chmod utiliza as letras "u", "g" e "o" para se referir àquelas triplas.
Qual Conjunto de Bits Aplica-se a Você?
Quando Unix decide o que você pode fazer, ele não utiliza todos os 9 bits. Unix pega a primeira tripla que aplica-se a você. Considere isto:
- ----rwxrwx 1 joe users 29 Mar 22 19:39 algumarquivo
Mesmo que joe seja dono desse arquivo, ele não pode acessá-lo. (Uma vez que joe é dono do arquivo, ele poderia dar acesso a ele próprio. Mais sobre isso depois). Também root é especial. A root é permitido rwx a todos os diretórios e rw a todos os arquivos. Em um arquivo, se quaisquer dos 3 bits estiverem configurados, root tem permissão de execução. Essa permissão especial é frequentemente desabilitada em sistemas de arquivos montados via rede.
O que "r", "w" e "x" realmente significam para um arquivo?
Para um arquivo, "read" [leitura] e "write" [escrita] são bastante intuitivos. O "x" para "execução" significa que o kernel pode tentar executar um arquivo. Para que isso funcione, o arquivo deve ser um executável (saída de um compilador) ou um script de shell com um "#!" na primeira linha. Para um diretório, as coisas são um pouco mais complexas. Com um diretório, a permissão "write" [escrita] significa que você pode criar novos arquivos em um diretório ou remover arquivos antigos. Ela as vezes surpreende as pessoas pois você pode remover um arquivo o qual você não pode ler. O comando rm do Unix testará tal situação e emitirá um alerta, porém você pode suprimir tal alerta com -f. E alertando ou não, se você deseja remover um arquivo ilegível de um diretório gravável, você pode. E rmdir não se preocupará em verificar de jeito nenhum.
O que "r", "w" e "x" realmente significam para um diretório?
Um diretório é um arquivo também, e a permissão "read" significa que você pode lê-lo. Porém você realmente não pode fazer muita coisa sem a permissão "x" também. Com diretórios, você usualmente tem ambas as permissões leitura e execução ou nenhuma. Em um diretório, aquele "x" é oficialmente chamado "permissão de busca". Você precisa de um "x" para utilizar um diretório em uma localização. Assim, se você tentar "cat /etc/passwd", você precisará do "x" em / e /etc. Você também precisa "x" para acessar o diretório com um cd. Suponha que você tenha permissão de leitura, mas não de busca (x) em um diretório. O que você pode fazer? Não muito. Você pode utilizar "ls" para visualizar os nomes de arquivos. Mesmo "ls -l" não funcionará. Acesso de leitura sem permissão de busca não é realmente útil. Ainda é melhor do que ter apenas permissão de escrita em um diretório... isso é completamente inútil. Eu não tenho visto qualquer outra documentação que declare isso explicitamente, de forma que permita-me repetir: escrita mas sem permissão de execução em um diretório não concede nada para ninguém. Suponha que você tenha permissão de busca (x), mas não permissão de leitura em um diretório. Agora você pode abrir arquivos em um diretório se acontecer de você saber o nome do arquivo. Você pode acessar o diretório [com cd]. E isso é tudo. Você não pode nem mesmo criar um arquivo novo. Adicionar permissão de escrita permitirá a você criar arquivos. E você pode então apagar arquivos se acontecer de você saber o nome deles.
Ligações Simbólicas São Especiais
As configurações de permissão em uma ligação simbólica são um pouco especiais também. Elas são completamente ignoradas. Muitas versões de Unix não tem um meio de mudá-las.
Os Bits Setuid e Setgid
Dá uma olhada nisto:
$ ls -l /etc/passwd /etc/shadow /usr/bin/passwd
- -r--r--r-- 1 root sys 14006 Jan 14 11:17 /etc/passwd
- -r-------- 1 root sys 8281 Jan 14 11:18 /etc/shadow
- -r-sr-sr-x 3 root sys 96244 Sep 5 2001 /usr/bin/passwd
O arquivo passwd é gravável apenas pelo root (lembre-se, root é especial. Ele pode gravar um arquivo que não tem permissões de escrita configuradas). O arquivo shadow, no qual senhas são armazenas, não pode nem mesmo ser lido por usuários comuns. Porém, joe deseja mudar a senha dele. Ele pode fazer isso executando /usr/bin/passwd. Perceba aquelas permissões r-s. O aplicativo passwd tem os bits suid e sgid configurados. Isso transforma os "x" em "s". Em octal, seria 6555. O aplicativo passwd é de propriedade do root. Quando joe o executa, ele não é executado como "joe". Ao invés disso, é executado como seu usuário que é o root. Assim, o aplicativo passwd pode mudar a senha de joe para ele. O bit sgid funciona da mesma maneira, exceto que ele faz com que o aplicativo passwd seja executado como grupo sys ao invés do grupo do joe. O suid e sgid não tem suas próprias posições no ls. Quando o bit suid está configurado, ls exibe um "s" no lugar de um "x" para a permissão de execução do proprietário. O que acontece se o bit suid estiver configurado, porém o bit de execução do proprietário estiver desligado? ls exibirá um "S" maiúsculo no caso. O bit sgid é exibido de uma maneira singular, exceto que ele interage com a permissão de execução do grupo. (O conceito do conjunto uid foi inventado por Dennis Ritchie quando ele estava desenvolvendo Unix).
Para expandir as coisas um pouco, enquanto que jos está executando o aplicativo suid-para-root passwd, "joe" é o uid real e "root" é o uid efetivo. O aplicativo passwd pode obter ambas dessas id's se ele desejar fazê-lo. Assim é como o aplicativo passwd sabe como permitir a joe mudar apenas a senha de joe.
O Bit Sticky
O padrão Posix diz que se o bit sticky estiver configurado para um diretório, a simples permissão de escrita no diretório não mais é suficiente para permitir que arquivos sejam removidos. Você deve adicionalmente ser dono do arquivo ou ser dono do diretório. root permanece sendo hábil para apagar de qualquer diretório independentemente das permissões. Antigamente esse bit servia a um outro propósito. Em alguns Sistemas Operacionais ele ainda serve. Eu completarei em um apêndice abaixo. O bit sticky afeta o bit de execução "outros" na exibição ls. Exceto pelo fato de que ele utiliza "t" e "T" no lugar de "s" e "S". Por exemplo:
drwxrwxrwt 5 root root 1024 Feb 11 20:43 /tmp
Naquele diretório /tmp acima, qualquer pessoa pode criar novos arquivos. Porém, por causa do bit sticky, um usuário não pode apagar os arquivos de um outro usuário.
Limitando Permissões de Arquivo com umask
Quando arquivos são criados, o aplicativo que os cria pode especificar a configuração inicial de permissão. Você pode sobrescrever isso com umask. O umask é um conjunto de bits de proibição. Existe um comando umask que te permite visualizar e mudar o umask. Por exemplo, "umask 022" proíbe escrita de grupo e escrita de outros em arquivos recém criados. Ou "umask 027" proíbe escrita de grupo e proíbe leitura, escrita e execução de outros. Você pode executar um "umask 0" para permitir que o aplicativo faça o que ele desejar a medida que ele cria aplicativos. Porém, você não pode ir mais além. Você não pode forçar um aplicativo a ligar um bit. A configuração de umask afeta arquivos, diretórios, pipes nomeados (também conhecidos como fifos), e arquivos especiais. Ele pode ou não pode afetar ligações simbólicas. Ele também afeta algumas formas de Comunicação Inter Processos (Inter Process Communication), mas isso está além do escopo deste artigo. E, acredite se quiser, sockets nomeados são imunes a umask. Essa imunidade é exigida por Posix.
Mudando Permissões de Arquivos com chmod
Apenas o proprietário de um arquivo pode mudar as permissões sobre um arquivo. Essa operação não é afetada de nenhuma maneira pela configuração de umask. Se você mudar as permissões sobre uma ligação simbólica, a ligação será seguida e você mudará o arquivo alvo. É possível que apenas o root tenha o poder de configurar um bit sticky de um arquivo. Como um exemplo, "chmod 700 algumarquivo" permitirá que o proprietário leia, escreva e execute o arquivo, enquanto que proíbe todo acesso a quaisquer outros usuários.
Utilizando Modo Simbólico com chmod e umask
Posix introduziu uma nova sintaxe para o comando chmod. A ideia foi que a nova sintaxe substituirá o uso de uma constante octal com o comando chmod. A constante octal ainda é válida e eu entendo que ela chegou para ficar. Porém, a nova sintaxe simbólica te permite mudar uns poucos bits sem o conhecimento do que os outros são. Por exemplo, digamos que eu deseje tornar um arquivo inacessível para outros, mas eu não desejo mudar o acesso para o usuário ou o grupo. Eu precisaria fazer:
ls -l arquivo
Olhar para o arquivo e descobrir as configurações atuais.
chmod 750 arquivo
Eu tive de determinar que os primeiros dois dígitos são atuais 7 e 5 antes que podesse executar meu comando chmod. Com a nova sintaxe, eu posso simplesmente fazer:
chmod o= arquivo
para desligar os 3 bits finais. Como um outro exemplo, "chmod u+x file" permitirá que o usuário execute o arquivo. Por outro lado, esses dois comandos são equivalentes:
chmod 750 arquivo
chmod u=rwx,g=rx,o= arquivo
e eu prefiro a primeira sintaxe.
O modo simbólico pode ser uma lista de especificações separada por vírgulas. Cada especificação tem três componentes: <quem><operação><bitlist>
A parte quem pode ser:
u (usuário)
g (grupo)
o (outros)
a (all - todos)
(o que seja permitido por umask (subconjunto de tudo))
A operação pode ser = ou - ou +
= (configura para bitlist)
- - (subtrai bitlist do bit atual
+ (adiciona bitllist aos bits atuais)
A bitlist pode ser uma das seguintes letras:
r (permissão de leitura - read)
w (permissão de escrita - write)
x (permissão de execução - execute)
X (permissão condicional de execução)
u (permissões atuais para o usuário)
g (permissões atuais para o grupo)
o (permissões atuais para outros)
s (configura uid ou configura gid)
t (sticky bit)
O "X" é o mesmo que "x" a menos que o arquivo seja um não-diretório e atualmente não tenha bits "x" configurados. O "s" (configura uid ou configura gid) pode apenas ser especificado para permissões de usuário ou de grupo. O "t" pode apenas ser especificado para permissões de usuário. Uns poucos exemplos com ajuda. Acima nós vimos que /usr/bin/passwd tinha 6555 (-r-sr-sr-x no ls). Aqui estão alguns caminhos para que aquilo seja alcançado:
chmod 6555 /usr/bin/passwd
chmod u=rxs,g=rxs,o=rx /usr/bin/passwd
chmod ug=rxs,o=rx /usr/bin/passwd
chmod a=rx,ug+s /usr/bin/passwd
E existem muitas outras maneiras de se fazer isso.
Para a maior parte, chmod é imune a umask em quaisquer daqueles bits que ele deseje configurar, não seja modificado por umask. Entretanto, sob uma condição, o comando chmod examinará a configuração atual de umask para determinar quais bits ele gostaria de configurar. Isso acontece quando você deixa o campo "quem" em branco. Como isso:
chmod =w algumarquivo
A diferença entre "a=w" and "=w" é sútil. Aqui está um exemplo que pode ajudar. Muitos aplicativos tentam criar arquivo com permissões 666 (-rw-rw-rw-). Porém, isso é modificado pelo umask. Suponha que você deseja configurar um arquivo para 666, porém modificado pelo umask atual. Nós poderíamos desligar todos os bits, então ligar os bits de leitura e escrita permitidos pelo umask atual:
chmod a=,=rw algumarquivo
E falando em umask, você pode utilizar argumentos simbólicos com o comando umask também. Entretanto, Posix, em sua sabedoria, decidiu que, nesse caso, a lógica seria reversa. Assim, se utilizar umask com um argumento octal, você especifica que os bits sejam proibidos. Porém, se você utiliza umask com um argumento simbólico, você especifica que os bits sejam permitidos. Então, esses são equivalentes:
umask 022
umask u=rwx,go=rx
Sumário
Neste ponto, você tem informação suficiente para entender a maior parte daqueles 12 bits de permissão. Existem vários casos especiais que eu ignorei ou camuflei. Nas postagens separadas abaixo, eu tratarei desses. A informação nesta primeira postagem é bastante universal. Um OS compatível com Posix deve suportar essas coisas. Isso cobre quase todas as versões de Unix lançadas nos últimos 10 anos. Os artigos seguintes discutem características que podem não serem universais.
Disponível em: <http://www.unix.com/tips-and-tutorials/19060-unix-file-permissions.html>. Acesso em: 01 set. 2014.
Jamenson Ferreira Espindula de Almeida Melo
Linux user nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJUBUtuAAoJECrgJcAIqGGAOSQIAILUDlkx0XJivgUEOh0newTr
DTxTWOOnHR2bf1NWUWWRzrFi/i3LJFH96IMOqfsSCQ5q/wopm4iN9Dvz5pnDd9nY
F24IJrSwiLQWQRSzmldRsCFaSfPth7s2cKMLdTYEIXkGCUmwFCnGDY43OCsoQVYC
Qz3sPXORXQCk3dsOvAJbJ75Zn3GeHa0LTRVLuQdn2slu3TvqyVXih5JqxkmHD0ld
D6ZtQBYfvk6z7Xug6GZFA52j7i8kZw+XBk3YgQuLTYpP8EkZlDsUDby/3SylDawU
6jpfTbU7c1es8EPqmEAjL/iC4LM9qJrnRcuTDqQyYCG5du+Y9UoBsm+FBros4Do=
=Gpfr
-----END PGP SIGNATURE-----
Hash: SHA1
Jaboatão dos Guararapes, PE, 02 de setembro de 2014.
Aqui está, em tradução livre para a língua portuguesa falada no Brasil, o texto postado por Perderabo "Permissões de Arquivos do Unix".
Unix File Permissions (Perderabo, 28/05/2005 - http://www.unix.com/tips-and-tutorials/19060-unix-file-permissions.html)
Introdução
Eu tenho visto alguma informação errada relativamente às permissões de arquivo do Unix. Eu tentarei esclarecer as coisas. Dá uma olhada neste exemplo de alguma saída do ls:
$ ls -ld /usr/bin /usr/bin/cat
drwxrwxr-x 3 root bin 8704 Sep 23 2004 /usr/bin
- -r-xr-xr-x 1 bin bin 9388 Jul 16 1997 /usr/bin/cat
$
Na primeira linha, aquele "root" diz que o diretório é propriedade do usuário chamado "root". E que "bin" ś o grupo do diretório. Você precisará entender usuários e grupos e eu presumirei que você entende. Meu objetivo é explicar aquelas "drwxrwxr-x" e "-r-xr-xr-x" coisas. Aquele campo é uma combinação do tipo do arquivo e permissão de acesso. Coletivamente, essa informação é algumas vezes chamada de modo do arquivo. E algumas vezes ela é chamada de permissões. Um bom lugar para começar é dando uma rápida olhada em como essa informação é atualmente armazenada no disco. A forma como ela é armazenada afeta um número de decisões que devem ser tomadas ao longo dos anos.
Como o "Modo do Arquivo" é armazenado.
No disco, informação acerca de um arquivo é armazenada em uma estrutura chamada um "inode". Cada arquivo tem o seu próprio inode. Um item de dados em um inode é chamado de "modo" e ele se parece com isto:
|---modo do arquivo---|
| |
|
| |--completo---|
|
|-tipo| | |-básico--|
| | | | |
oo0 000 000 000 000 000
... ... ... ... ... ...
| | | | |
| | | | |---- rwx para outros
| | | |
| | | |-------- rwx para grupo
| | |
| | |------------ rwx para usuário
| |
| |---------------- configura uid, configura gid, sticky bit
|
|---------------------- tipo do arquivo: comum (-)
diretório (d)
carácter especial (c)
bloco especial (b)
fifo (p)
ligação simbólica (l)
socket (s)
Eu entendo que o "modo" realmente significa simplesmente as permissões e que o tipo do arquivo foi enfiado para dentro para economizar espaço. Porém, o autor do aplicativo ls está tratando o modo como um item único. Eis o porque de o tipo do arquivo ser o primeiro carácter da sequência de permissão no saída de "ls -l". O tipo do arquivo usualmente será um dos sete tipos que eu mostrei acima. Algumas versões de Unix adicionarão alguns mais. A única outra coisa a saber a partir do formato é que não existe mais compartimento para adicionar mais bits de permissão.
Representando aquelas permissões em octal
O aplicativo ls pode exibir, digamos, "rwxrwxrwx" para as permissões em um arquivo. Também é muito comum utilizar um número octal para expressar as permissões em um arquivo. E como você vê acima, assim é como elas são armazenadas. Você pode escutar alguém dizer que alguns tem permissões 777. Isso é o mesmo que "rwxrwxrwx" e muito mais fácil de pronunciar. Então você precisa saber como convertê-los. Três dígitos binários ou bits correspondem a um dígito octal:
421
rwx
Assim, o bit de leitura tem valor 4, o bit de escrita tem valor 2, e o bit de execução tem valor 1. Você simplesmente adiciona tais valores para obter um dígito octal. Então, "-rwxrwxrwx" é 777. E "-rwxr-x---" é 750. Se você ainda não consegue ver como ir de "r-x" para 5, talvez esta tabela ajude:
- --- = 0
- --x = 1
- -w- = 2
- -wx = 3
r-- = 4
r-x = 5
rw- = 6
rwx = 7
Perceba que precisamos de 4 dígitos octais para exprimir todos os bits de permissões. Os primeiros três bits são especiais e são frequentemente zero. E você quase sempre aprende primeiro sobre os 9 bits seguintes. Algumas pessoas param aí e nunca aprendem aqueles primeiros três bits. Porém, existem 12 bits de permissão, não apenas 9. Dito isso, vamos agora dar uma olhada nos 9 bits seguintes.
Os Bits de Permissão Básicos
Nós temos 3 triplas: uma tripla para o usuário, uma tripla para o grupo, e uma tripla para outros. Algumas vezes o "usuário" é chamado de proprietário. E algumas vezes "outros" é chamado de "mundo" Eu utilizarei "usuário" e "outros" pois o comando chmod utiliza as letras "u", "g" e "o" para se referir àquelas triplas.
Qual Conjunto de Bits Aplica-se a Você?
Quando Unix decide o que você pode fazer, ele não utiliza todos os 9 bits. Unix pega a primeira tripla que aplica-se a você. Considere isto:
- ----rwxrwx 1 joe users 29 Mar 22 19:39 algumarquivo
Mesmo que joe seja dono desse arquivo, ele não pode acessá-lo. (Uma vez que joe é dono do arquivo, ele poderia dar acesso a ele próprio. Mais sobre isso depois). Também root é especial. A root é permitido rwx a todos os diretórios e rw a todos os arquivos. Em um arquivo, se quaisquer dos 3 bits estiverem configurados, root tem permissão de execução. Essa permissão especial é frequentemente desabilitada em sistemas de arquivos montados via rede.
O que "r", "w" e "x" realmente significam para um arquivo?
Para um arquivo, "read" [leitura] e "write" [escrita] são bastante intuitivos. O "x" para "execução" significa que o kernel pode tentar executar um arquivo. Para que isso funcione, o arquivo deve ser um executável (saída de um compilador) ou um script de shell com um "#!" na primeira linha. Para um diretório, as coisas são um pouco mais complexas. Com um diretório, a permissão "write" [escrita] significa que você pode criar novos arquivos em um diretório ou remover arquivos antigos. Ela as vezes surpreende as pessoas pois você pode remover um arquivo o qual você não pode ler. O comando rm do Unix testará tal situação e emitirá um alerta, porém você pode suprimir tal alerta com -f. E alertando ou não, se você deseja remover um arquivo ilegível de um diretório gravável, você pode. E rmdir não se preocupará em verificar de jeito nenhum.
O que "r", "w" e "x" realmente significam para um diretório?
Um diretório é um arquivo também, e a permissão "read" significa que você pode lê-lo. Porém você realmente não pode fazer muita coisa sem a permissão "x" também. Com diretórios, você usualmente tem ambas as permissões leitura e execução ou nenhuma. Em um diretório, aquele "x" é oficialmente chamado "permissão de busca". Você precisa de um "x" para utilizar um diretório em uma localização. Assim, se você tentar "cat /etc/passwd", você precisará do "x" em / e /etc. Você também precisa "x" para acessar o diretório com um cd. Suponha que você tenha permissão de leitura, mas não de busca (x) em um diretório. O que você pode fazer? Não muito. Você pode utilizar "ls" para visualizar os nomes de arquivos. Mesmo "ls -l" não funcionará. Acesso de leitura sem permissão de busca não é realmente útil. Ainda é melhor do que ter apenas permissão de escrita em um diretório... isso é completamente inútil. Eu não tenho visto qualquer outra documentação que declare isso explicitamente, de forma que permita-me repetir: escrita mas sem permissão de execução em um diretório não concede nada para ninguém. Suponha que você tenha permissão de busca (x), mas não permissão de leitura em um diretório. Agora você pode abrir arquivos em um diretório se acontecer de você saber o nome do arquivo. Você pode acessar o diretório [com cd]. E isso é tudo. Você não pode nem mesmo criar um arquivo novo. Adicionar permissão de escrita permitirá a você criar arquivos. E você pode então apagar arquivos se acontecer de você saber o nome deles.
Ligações Simbólicas São Especiais
As configurações de permissão em uma ligação simbólica são um pouco especiais também. Elas são completamente ignoradas. Muitas versões de Unix não tem um meio de mudá-las.
Os Bits Setuid e Setgid
Dá uma olhada nisto:
$ ls -l /etc/passwd /etc/shadow /usr/bin/passwd
- -r--r--r-- 1 root sys 14006 Jan 14 11:17 /etc/passwd
- -r-------- 1 root sys 8281 Jan 14 11:18 /etc/shadow
- -r-sr-sr-x 3 root sys 96244 Sep 5 2001 /usr/bin/passwd
O arquivo passwd é gravável apenas pelo root (lembre-se, root é especial. Ele pode gravar um arquivo que não tem permissões de escrita configuradas). O arquivo shadow, no qual senhas são armazenas, não pode nem mesmo ser lido por usuários comuns. Porém, joe deseja mudar a senha dele. Ele pode fazer isso executando /usr/bin/passwd. Perceba aquelas permissões r-s. O aplicativo passwd tem os bits suid e sgid configurados. Isso transforma os "x" em "s". Em octal, seria 6555. O aplicativo passwd é de propriedade do root. Quando joe o executa, ele não é executado como "joe". Ao invés disso, é executado como seu usuário que é o root. Assim, o aplicativo passwd pode mudar a senha de joe para ele. O bit sgid funciona da mesma maneira, exceto que ele faz com que o aplicativo passwd seja executado como grupo sys ao invés do grupo do joe. O suid e sgid não tem suas próprias posições no ls. Quando o bit suid está configurado, ls exibe um "s" no lugar de um "x" para a permissão de execução do proprietário. O que acontece se o bit suid estiver configurado, porém o bit de execução do proprietário estiver desligado? ls exibirá um "S" maiúsculo no caso. O bit sgid é exibido de uma maneira singular, exceto que ele interage com a permissão de execução do grupo. (O conceito do conjunto uid foi inventado por Dennis Ritchie quando ele estava desenvolvendo Unix).
Para expandir as coisas um pouco, enquanto que jos está executando o aplicativo suid-para-root passwd, "joe" é o uid real e "root" é o uid efetivo. O aplicativo passwd pode obter ambas dessas id's se ele desejar fazê-lo. Assim é como o aplicativo passwd sabe como permitir a joe mudar apenas a senha de joe.
O Bit Sticky
O padrão Posix diz que se o bit sticky estiver configurado para um diretório, a simples permissão de escrita no diretório não mais é suficiente para permitir que arquivos sejam removidos. Você deve adicionalmente ser dono do arquivo ou ser dono do diretório. root permanece sendo hábil para apagar de qualquer diretório independentemente das permissões. Antigamente esse bit servia a um outro propósito. Em alguns Sistemas Operacionais ele ainda serve. Eu completarei em um apêndice abaixo. O bit sticky afeta o bit de execução "outros" na exibição ls. Exceto pelo fato de que ele utiliza "t" e "T" no lugar de "s" e "S". Por exemplo:
drwxrwxrwt 5 root root 1024 Feb 11 20:43 /tmp
Naquele diretório /tmp acima, qualquer pessoa pode criar novos arquivos. Porém, por causa do bit sticky, um usuário não pode apagar os arquivos de um outro usuário.
Limitando Permissões de Arquivo com umask
Quando arquivos são criados, o aplicativo que os cria pode especificar a configuração inicial de permissão. Você pode sobrescrever isso com umask. O umask é um conjunto de bits de proibição. Existe um comando umask que te permite visualizar e mudar o umask. Por exemplo, "umask 022" proíbe escrita de grupo e escrita de outros em arquivos recém criados. Ou "umask 027" proíbe escrita de grupo e proíbe leitura, escrita e execução de outros. Você pode executar um "umask 0" para permitir que o aplicativo faça o que ele desejar a medida que ele cria aplicativos. Porém, você não pode ir mais além. Você não pode forçar um aplicativo a ligar um bit. A configuração de umask afeta arquivos, diretórios, pipes nomeados (também conhecidos como fifos), e arquivos especiais. Ele pode ou não pode afetar ligações simbólicas. Ele também afeta algumas formas de Comunicação Inter Processos (Inter Process Communication), mas isso está além do escopo deste artigo. E, acredite se quiser, sockets nomeados são imunes a umask. Essa imunidade é exigida por Posix.
Mudando Permissões de Arquivos com chmod
Apenas o proprietário de um arquivo pode mudar as permissões sobre um arquivo. Essa operação não é afetada de nenhuma maneira pela configuração de umask. Se você mudar as permissões sobre uma ligação simbólica, a ligação será seguida e você mudará o arquivo alvo. É possível que apenas o root tenha o poder de configurar um bit sticky de um arquivo. Como um exemplo, "chmod 700 algumarquivo" permitirá que o proprietário leia, escreva e execute o arquivo, enquanto que proíbe todo acesso a quaisquer outros usuários.
Utilizando Modo Simbólico com chmod e umask
Posix introduziu uma nova sintaxe para o comando chmod. A ideia foi que a nova sintaxe substituirá o uso de uma constante octal com o comando chmod. A constante octal ainda é válida e eu entendo que ela chegou para ficar. Porém, a nova sintaxe simbólica te permite mudar uns poucos bits sem o conhecimento do que os outros são. Por exemplo, digamos que eu deseje tornar um arquivo inacessível para outros, mas eu não desejo mudar o acesso para o usuário ou o grupo. Eu precisaria fazer:
ls -l arquivo
Olhar para o arquivo e descobrir as configurações atuais.
chmod 750 arquivo
Eu tive de determinar que os primeiros dois dígitos são atuais 7 e 5 antes que podesse executar meu comando chmod. Com a nova sintaxe, eu posso simplesmente fazer:
chmod o= arquivo
para desligar os 3 bits finais. Como um outro exemplo, "chmod u+x file" permitirá que o usuário execute o arquivo. Por outro lado, esses dois comandos são equivalentes:
chmod 750 arquivo
chmod u=rwx,g=rx,o= arquivo
e eu prefiro a primeira sintaxe.
O modo simbólico pode ser uma lista de especificações separada por vírgulas. Cada especificação tem três componentes: <quem><operação><bitlist>
A parte quem pode ser:
u (usuário)
g (grupo)
o (outros)
a (all - todos)
(o que seja permitido por umask (subconjunto de tudo))
A operação pode ser = ou - ou +
= (configura para bitlist)
- - (subtrai bitlist do bit atual
+ (adiciona bitllist aos bits atuais)
A bitlist pode ser uma das seguintes letras:
r (permissão de leitura - read)
w (permissão de escrita - write)
x (permissão de execução - execute)
X (permissão condicional de execução)
u (permissões atuais para o usuário)
g (permissões atuais para o grupo)
o (permissões atuais para outros)
s (configura uid ou configura gid)
t (sticky bit)
O "X" é o mesmo que "x" a menos que o arquivo seja um não-diretório e atualmente não tenha bits "x" configurados. O "s" (configura uid ou configura gid) pode apenas ser especificado para permissões de usuário ou de grupo. O "t" pode apenas ser especificado para permissões de usuário. Uns poucos exemplos com ajuda. Acima nós vimos que /usr/bin/passwd tinha 6555 (-r-sr-sr-x no ls). Aqui estão alguns caminhos para que aquilo seja alcançado:
chmod 6555 /usr/bin/passwd
chmod u=rxs,g=rxs,o=rx /usr/bin/passwd
chmod ug=rxs,o=rx /usr/bin/passwd
chmod a=rx,ug+s /usr/bin/passwd
E existem muitas outras maneiras de se fazer isso.
Para a maior parte, chmod é imune a umask em quaisquer daqueles bits que ele deseje configurar, não seja modificado por umask. Entretanto, sob uma condição, o comando chmod examinará a configuração atual de umask para determinar quais bits ele gostaria de configurar. Isso acontece quando você deixa o campo "quem" em branco. Como isso:
chmod =w algumarquivo
A diferença entre "a=w" and "=w" é sútil. Aqui está um exemplo que pode ajudar. Muitos aplicativos tentam criar arquivo com permissões 666 (-rw-rw-rw-). Porém, isso é modificado pelo umask. Suponha que você deseja configurar um arquivo para 666, porém modificado pelo umask atual. Nós poderíamos desligar todos os bits, então ligar os bits de leitura e escrita permitidos pelo umask atual:
chmod a=,=rw algumarquivo
E falando em umask, você pode utilizar argumentos simbólicos com o comando umask também. Entretanto, Posix, em sua sabedoria, decidiu que, nesse caso, a lógica seria reversa. Assim, se utilizar umask com um argumento octal, você especifica que os bits sejam proibidos. Porém, se você utiliza umask com um argumento simbólico, você especifica que os bits sejam permitidos. Então, esses são equivalentes:
umask 022
umask u=rwx,go=rx
Sumário
Neste ponto, você tem informação suficiente para entender a maior parte daqueles 12 bits de permissão. Existem vários casos especiais que eu ignorei ou camuflei. Nas postagens separadas abaixo, eu tratarei desses. A informação nesta primeira postagem é bastante universal. Um OS compatível com Posix deve suportar essas coisas. Isso cobre quase todas as versões de Unix lançadas nos últimos 10 anos. Os artigos seguintes discutem características que podem não serem universais.
Disponível em: <http://www.unix.com/tips-and-tutorials/19060-unix-file-permissions.html>. Acesso em: 01 set. 2014.
Jamenson Ferreira Espindula de Almeida Melo
Linux user nº 166197
https://linuxcounter.net/cert/166197.png
Impressão digital da chave:
234D 1914 4224 7C53 BD13 6855 2AE0 25C0 08A8 6180
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBAgAGBQJUBUtuAAoJECrgJcAIqGGAOSQIAILUDlkx0XJivgUEOh0newTr
DTxTWOOnHR2bf1NWUWWRzrFi/i3LJFH96IMOqfsSCQ5q/wopm4iN9Dvz5pnDd9nY
F24IJrSwiLQWQRSzmldRsCFaSfPth7s2cKMLdTYEIXkGCUmwFCnGDY43OCsoQVYC
Qz3sPXORXQCk3dsOvAJbJ75Zn3GeHa0LTRVLuQdn2slu3TvqyVXih5JqxkmHD0ld
D6ZtQBYfvk6z7Xug6GZFA52j7i8kZw+XBk3YgQuLTYpP8EkZlDsUDby/3SylDawU
6jpfTbU7c1es8EPqmEAjL/iC4LM9qJrnRcuTDqQyYCG5du+Y9UoBsm+FBros4Do=
=Gpfr
-----END PGP SIGNATURE-----
Assinar:
Comentários (Atom)