Introdução

Tenho visto alguns desinformação quanto Unix arquivo permissões. Vou tentar definir o recorde reta. Dê uma olhada neste exemplo de alguns resultados de ls:
Na primeira linha, que a "raiz", diz que o diretório é propriedade do usuário chamado "root". E que "bin" é o grupo do diretório. Você precisará entender os usuários e grupos e eu vou assumir que você faz. O meu objectivo é o de explicar que "drwxrwxr-x" e "-r-xr-xr-x" coisas. Esse campo é uma combinação do tipo de arquivo e acesso permissão. Colectivamente, esta informação é muitas vezes chamado a Modo de arquivo. E às vezes é chamado de permissões. Um bom lugar para começar é tomando uma rápida olhada em como essa informação é efectivamente armazenada no disco. A forma como são armazenados afecta uma série de decisões que foram feitas ao longo dos anos.

Como o "File Mode" é armazenado.

Em disco, a informação sobre um arquivo é armazenado em uma estrutura denominada "nodo". Cada arquivo terá o seu próprio nodo. Um item de dados em um nodo é chamado de "modo" e olha como esta:
Penso que o "modo" significa, na realidade, apenas as permissões e que o tipo de arquivo foi empurradas para economizar espaço. Mas o autor do programa é tratar ls o modo como um único item. É por isso que o tipo de arquivo é o primeiro caractere da seqüência na permissão "ls-l" saída. O tipo de arquivo geralmente será um dos sete tipos, que eu mostrar acima. Algumas versões do Unix vai acrescentar mais alguns. A única outra coisa a notar a partir dos dados esquema é que não há espaço para adicionar mais permissão bits.

Representando essas permissões em octal

O ls programa pode exibir, digamos, "rwxrwxrwx" para as permissões em um arquivo. Também é muito comum a utilização de um número octal de expressar as permissões em um arquivo. E como você vê acima, esta é a forma como eles são armazenados. Você pode ouvir alguém dizer que tem cerca de 777 permissões. Esta é a mesma como "rwxrwxrwx" e muito mais fácil de pronunciar. Então você precisa saber como convertê-las. Três dígitos binários ou bits corresponde a um dígito octal:

Portanto, a "ler pouco vale 4, a escrever pouco vale 2 e executar o pouco vale 1. Você acabou de adicionar estes até obter um dígito octal. Então"-rwxrwxrwx "é 777. E"-rwxr-x -- - "é 750. Se você ainda não pode ver como se obtém a partir de" rx "a 5, talvez esta tabela vai ajudar:

Nota precisamos Octol 4 dígitos para expressar toda a permissão bits. Os primeiros três bits são especiais e estão frequentemente zero. E você quase sempre aprender sobre a rasteira 9 bits primeiro. Algumas pessoas lá e nunca parar de aprender os primeiros três bits. Mas há 12 bits permissão, e não apenas 9. Dito isto, vamos agora dar uma olhada na rasteira 9 bits.

O Básico Permissão Bits

Temos 3 triplos: um triplo para o utilizador, um triplo para o grupo, e um triplo para os outros. Às vezes, o "usuário" é chamado o proprietário. E, às vezes, os "outros" é chamado de "mundo". Vou usar o "usuário" e "outros" porque o comando chmod utiliza as letras ug e o para se referir a essas triplos.

Conjunto de bits que se aplica a você?

Quando Unix decida o que você pode fazer, ele não usa todos os 9 bits. Unix escolhe a primeira tripla que se aplica a você. Considere o seguinte: Mesmo joe possui esse arquivo, ele não pode acessá-lo. (Desde joe possui o arquivo, ele pode dar-se o acesso. Saiba mais sobre isso mais tarde.) Também raiz é especial. RWX raiz é concedido a todos os diretórios e rw para todos os arquivos. Em um ficheiro, se qualquer um dos 3 x bits são fixados, raiz tem permissão executar. Esta permissão especial é frequentemente deficientes na rede montada arquivos.

O que fazer e x rw realmente significa para um arquivo?

Para um arquivo, "ler" e "escrever" é bastante intuitivo. O x para "executar" significa que o kernel pode tentar executar o arquivo. Para que isso funcione, o arquivo deve ser um executável (saída de um compilador), ou um shell script com um "#!" primeira linha. Para um diretório, as coisas são um pouco mais complexa. Com um repertório, "escrever" permissão significa que você pode criar novos arquivos no diretório ou remover arquivos antigos. Por vezes, surpreende as pessoas que você pode remover um arquivo que você não pode ler. O comando rm unix para que irá testar e emitir um aviso, mas você pode suprimir esse aviso com-f. E advertência ou não, se você quiser remover um arquivo de um ilegível writable diretório, você pode. Rmdir e não vai incomodar a verificar em todos.

O que fazer e x rw realmente significa para um diretório?

Um diretório é um arquivo também, e "ler" permissão significa que você pode lê-lo. Mas você realmente não pode fazer muito sem permissão x bem. Com diretórios, você costuma ler e executar ambos têm permissão ou não. Em um diretório, que x é oficialmente chamada de "pesquisa permissão". Você x necessidade de usar um diretório em um caminho. Então, se você tentar "cat / etc / passwd", você precisará x on / e / etc Você também precisa x para o CD em um diretório. Suponha que você tenha lido, mas não busca (x) permissão de um diretório. O que você pode fazer? Não muito. Você pode usar "ls" para ver os nomes de arquivos. Mesmo "ls-l" não vai funcionar. Ler o acesso sem permissão pesquisa não é muito útil. Ainda que seja melhor do que ter apenas permissão escrever em um diretório ... isso é completamente inútil. Eu não vi qualquer outra documentação que declare isso explicitamente, portanto deixe-me repeti-lo: escrever, mas não executar permissão em um diretório subvenções nada em all.Suppose você busca (x) permissão, mas não ler permissão em um diretório. Agora você pode abrir arquivos no diretório se você souber o nome do arquivo de. Você pode cd para o diretório. E isso é tudo. Você não pode até mesmo criar um novo arquivo. Adicionando permissão escrita permite-lhe criar ficheiros. E então você pode apagar arquivos se você sabe seu nome.

Links simbólicos são especiais

As configurações de permissão em um link simbólico é um pouco especial, também. Eles são completamente ignoradas. Muitas versões do Unix têm nada para mudá-los.

O setuid e do setgid Bits

Dê uma olhada nisto: O arquivo passwd é gravável apenas pelo root (Lembre-se de raiz é especial. Pode escrever um arquivo que não tem permissões definidas escrever). A sombra arquivo, que é onde as senhas são armazenados, nem sequer pode ser lida por usuários comuns. Mas Joe quer mudar sua senha. Ele pode fazer isso executando / usr / bin / passwd. Aviso aqueles rs permissões. O programa tem o SUID passwd e sgid bits set. Isto transforma os x's em s's. Em octal, seria 6555. O programa é de propriedade da passwd root. Joe Quando executa-lo, ele não é executado como "Joe". Em vez disso, ele funciona como proprietário que é raiz. Portanto, o programa pode alterar joe passwd a senha para ele. O sgid bit funciona da mesma maneira, exceto que faz com que o programa seja executado passwd com o grupo em vez de Joe's sys grupo. O SUID e sgid não obtiver a sua própria posição no ls. Quando o SUID bit é definido, ls mostra como, em vez de machado para o proprietário executar permissão. E se o SUID bit é definido, mas o proprietário executar bit está desligado? ls exibirá um capital S, no caso. O sgid bit é exibida de forma semelhante, exceto que ela interage com o grupo executar permissão. (O conceito foi fixado uid inventado por Dennis Ritchie que ele estava desenvolvendo Unix.)

Para expandir um pouco sobre as coisas, enquanto Joe está executando o SUID-to-root passwd program, "Joe" é o verdadeiro uid e "raiz" é o uid eficaz. Passwd O programa pode obter esses dois tipos de id's, se quiser. Esta é a forma como o programa sabe passwd para permitir apenas joe joe para alterar a senha.

O Sticky Bit

O Posix Norma diz que, se o bit sticky está definido em um diretório, a mera permissão escrever sobre o diretório já não é suficiente para permitir que arquivos sejam removidos. Você deve também o próprio dono do arquivo ou diretório. raiz continua a ser possível eliminar a partir de qualquer diretório independentemente das permissões. Anteriormente este bit servido um outro objectivo. Em alguns SO's ela ainda faz. Vou elaborar em um apêndice abaixo. O adesivo pouco afeta o "outro" executar bits no ls exibir. Só que ele usa em vez de t e T s e S. Por exemplo: Nesse / tmp diretório acima, qualquer um pode criar novos arquivos. Mas por causa do pouco pegajosa, um usuário não pode apagar os arquivos do outro usuário.

Limitar Arquivo com Permissões umask

Quando os arquivos são criados no programa que cria pode especificar a configuração inicial permissão. Você pode ignorar que, com umask. O umask é um conjunto de proibir bits. Umask Existe um comando que permite visualizar e alterar o umask. Por exemplo, "umask 022" proíbe grupo escrever e escrever sobre outros arquivos recém-criados. Ou "umask 027" proíbe grupo escrever e outros que proíbe ler, escrever ou executar. Você pode fazer um "umask 0" para deixar o programa fazer o que quer que ele cria programas. Mas você não pode ir mais longe. Você não pode forçar um programa para transformar um pouco sobre. O umask configuração afeta arquivos, diretórios, named pipes (aka FIFOs), e os arquivos especiais. Pode ou não afecta ligações simbólicas. Afecta igualmente Somes formas de Inter Process Communication mas isso está além do escopo deste artigo. E acredite ou não, chamado soquetes estão isentos umask. Esta isenção é necessário por Posix.

Alterar Permissões de Arquivo chmod

Apenas o proprietário de um arquivo ou raiz pode alterar as permissões em um arquivo. Esta operação é não a todos os afectados pela configuração umask. Se você alterar as permissões de uma ligação simbólica, o link será seguido, e você vai mudar o arquivo de destino. É possível que só raiz terá o poder de definir um arquivo de pouco pegajosa. Como um exemplo, "chmod 700 umficheiro" wil deixar o proprietário ler, escrever e executar o arquivo, ao mesmo tempo que recusa o acesso a todos os outros utilizadores.

Modo de Usar Simbólico chmod e umask

Posix introduziu uma nova sintaxe para o comando chmod. A idéia era que a nova sintaxe irá substituir a utilização de uma constante octal com o comando chmod. O octal constante ainda é permitida, e eu acho que é para ficar. Mas a nova sintaxe simbólica permite alterar alguns bits sem saber o que os outros estão. Por exemplo, digamos que eu quero fazer um arquivo inacessíveis a outros, mas não o que eu faço para mudar o acesso para o usuário ou o grupo. Eu teria que fazer:
ls-l arquivo
Olhe para arquivo e descobrir as configurações atuais.
chmod 750 arquivo
Eu tinha de determinar que os dois primeiros dígitos são correntes 7 e 5 antes que eu pudesse fazer o meu comando chmod. Com a nova sintaxe, não posso simplesmente fazer:
chmod o \u003d arquivo
para desligar o final 3 bits. Como outro exemplo, "chmod u + x arquivo" permitirá ao usuário executar o arquivo. Por outro lado, estes dois comandos são equivalentes:
chmod 750 arquivo
chmod u \u003d RWX, g \u003d rx, o \u003d arquivo
e eu prefiro a primeira sintaxe.

O modo simbólico pode ser uma lista separada por vírgulas de especificações. Cada especificação tem três componentes: <who> <operation> <bitlist> O X é o mesmo que x, a menos que o arquivo é um nondirectory e atualmente não tem nenhum x bits set. A s (set uid gid ou conjunto), só pode ser especificado para o utilizador ou grupo permissões. O t só pode ser especificado para as permissões do usuário. Alguns exemplos de ajuda. Acima vimos / usr / bin / passwd foi 6555 (-r-sr-sr-x em ls). Aqui estão algumas maneiras que poderiam ser alcançados:
chmod 6555 / usr / bin / passwd
chmod u \u003d rxs, g \u003d rxs, o \u003d rx / usr / bin / passwd
chmod ug \u003d rxs, o \u003d rx / usr / bin / passwd
chmod a \u003d rx, ug + s / usr / bin / passwd
E há muitas outras maneiras de fazer isso.

Para a maior parte chmod é imune a umask em que, qualquer que seja bits que pretende configurar não obtiver modificado pela umask. No entanto, sob uma condição, o comando chmod examinará a definição actual de umask para determinar quais bits que gostaria de definir. Isto acontece quando você deixa o "quem" campo em branco. Como esta:
chmod \u003d w umficheiro
A diferença entre "um \u003d w" e "w \u003d" é sutil. Aqui está um exemplo que pode ajudar. Muitos programas tentar criar o arquivo com 666 (-rw-rw-rw-) permissões. Mas este fica modificado pela umask. Suponha que você queira definir a um arquivo para 666, mas modificada pelo actual umask. Podemos desligar todos os bits e, em seguida, ligue ler e escrever bits que são permitidas pela actual umask:

chmod a \u003d, \u003d rw umficheiro

E falando de umask, você pode usar argumentos simbólico com o comando umask também. Contudo, Posix, Na sua sabedoria, decidiu que, neste caso a lógica seria revertida. Portanto, se utilizar umask octal com um argumento que você especificar os bits a ser proibida. Mas se você usar umask com um argumento simbólico, você especifica os bits permitir. Portanto, estes são equivalentes:
umask 022
umask u \u003d RWX, ir \u003d rx

Resumo

Nesse ponto, você tem informação suficiente para compreender essas maioritariamente 12 permissão bits. Há vários casos muito especiais que eu tenho ignorado ou glossed cargo. Em distintos lugares abaixo irei abordar estas. A informação contida neste primeiro post é bastante universal. A Posix compliant SO deve apoiar essas coisas. Que abrange quase todas as versões do Unix libertados nos últimos 10 anos. Os artigos seguintes discutem características que não pode ser universal.

Eu já mencionei anteriormente que, quando um diretório tem o sticky bit, um arquivo pode ser apagado apenas pelo proprietário do arquivo ou o proprietário do diretório. Este comportamento é determinado por Posix e agora é bastante universal. No entanto não foi esse o propósito original da pegajosa bit. Vejo que a Posix definição do comando ls realmente chama a sticky bit "restrito a supressão bandeira". O constante na C cabeçalho arquivos para este bit é S_ISVTX. O svtx stands for salvar texto e isto revela o propósito original da bit.

A ideia original era que, se o bit sticky foi definido, o segmento de texto de um processo iria permanecer na área de swap. Isto lhe permitirá ser lido na memória com um único disco lido. Inicialmente, utilizou um sistema Unix com uma dimensão de 512 blocos e os blocos tende a disseminar-se. Por isso, seria necessário tempo para recolher o texto segmento e carregá-lo na memória. Na primeira não houve paginação, só trocando. E, para executar um programa teria que ser completamente carregado na memória. Agora, página de um programa falha na memória. As páginas são carregadas em que são necessários. Então, é o uso do adesivo original pouco morto? Bem, não. Depende do SO.

Com o HP-UX, esse uso ainda está viva e está documentado no HP-UX chmod (2) página man. O uso é isto? De O HP-UX Kernel e Performance Tuning Guide via HP-UX Faq:
"Quando os aplicativos estão localizados remotamente, definir a" sticky bit "sobre os aplicativos binários, usando o comando chmod + t. Isto diz ao sistema para a página do texto para o disco local. Caso contrário, é" recuperada "através da rede. Dos claro, isso só se aplica quando há real paginação ocorrendo. Mais recentemente, existe um parâmetro do kernel, page_text_to_local, que, quando configurado para 1, vai dizer ao kernel para todas as páginas NFS executável texto para páginas locais swap. "

No Solaris, não há sinal do original uso do sticky bit, no entanto, de acordo com o Solaris chmod (2) página man:
"Se um arquivo regular não é executável e tem S_ISVTX conjunto, o arquivo é assumido como sendo um ficheiro swap. Nesse caso, o sistema da página cache não será utilizado para manter o arquivo de dados. S_ISVTX Se o bit é definido em qualquer outro arquivo, os resultados não são especificadas. "

Então, você precisará verificar o chmod (2) man page para o seu sistema operacional para ver o efeito que, se for o caso, o adesivo tem pouco em um arquivo. Além disso, esteja ciente de que, quando existe um efeito, o SO pode restringir a definição de uma pegajosa pouco a raiz. Por exemplo, com a HP-UX, um utilizador mal intencionado poderia dar um monte de sticky bits e execute o sistema fora do espaço de swap.

HP-UX efectivamente tem também alguns links simbólicos que têm o bit sticky. Irei abordar esta abaixo.

Nós brevemente referido que os arquivos tenham um usuário e grupo que lhes estão associadas. Originalmente, era apenas o usuário e grupo de quem os criou. Mas, inicialmente, um usuário pode estar em apenas um grupo de cada vez. BSD introduziu o conceito de que um usuário pode estar em vários grupos simutaneously. Portanto, em BSD, grupo que foi usado? BSD decidiu usar o grupo do diretório que continha o arquivo recém-criado.

Muitas versões modernas de unix tentar tê-lo em ambos os sentidos. Um recém-criado grupo recebe o arquivo do diretório, a menos que o usuário tenha o setgid bit. Nesse caso, o recém-criado grupo recebe o arquivo do diretório.

E há uma exceção a isso! Alterar o proprietário ou grupo de um ficheiro tem preocupações de segurança. Por esse motivo, algumas versões do Unix irá, eventualmente, proibir um usuário diferente de root alterar o dono de um arquivo. Além disso, um usuário está proibido de mudar o grupo de um arquivo a menos que ele seja um membro do novo grupo. Esta restrição se sobrepõe à setgid bits em um diretório, se necessário.

Não estamos a terminar com esta Definir Gid pouco ainda ... Unix tem um conceito de arquivo travamento. Arquivo bloqueio está além do âmbito desta discussão. Mas você precisa saber que o arquivo bloqueio vem em dois sabores: consultivo e manditory. Que sabor é aplicável a um determinado arquivo, dependendo da permissão definições. Se o grupo executará bit está desligado, mas o setgid bit é relativa, qualquer arquivo que travem os arquivos são manditory.

Inútil Bit Combinação?

Cada referência que eu tenho visto que diz setgid on / off é um grupo executar outra combinação inútil. Mesmo Richard Stevens (em Programação avançada em ambiente Unix) Diz: "Uma vez que o set-group-ID bit não faz sentido quando o grupo executá-bit estiver desligado, os designers de SVR3 escolheu esta forma de indicar que o bloqueio de um ficheiro está a ser bloqueada e não maditory consultivo travamento."

Bem considerar este caso: Fred dirige o Departamento de Recursos Humanos. Fred e seu grupo freqüentemente precisam consultar os dias de férias utilizados para os trabalhadores. Fred decide a escrever um programa para os funcionários podem consultar os seus próprios dias de férias utilizados. Por questões de segurança, Fred faz este programa fazer um monte de madeira. Fred decide que ele não quer que o seu grupo para usar esse programa. Têm outras ferramentas que não atravancar o seu diário. Então Fred faz:
chown fred: hr vdays
chmod 2701 vdays
Agora vdays o programa não pode ser executado por membros da hora (excepto fred). Mas ele pode ser executado por todos os outros. E ele vai assumir o gid da hora, quando ele correr. Tenho escrito um ensaio programa, configurá-lo como esta, e que execute-o em ambos os Solaris e HP-UX. Funciona.

Efeito sobre o ls saída

Embora esta combinação bit pode ser útil em alguns casos limitados, para melhor ou para pior, ele terá dois efeitos. O vdays programa não funciona, mas se é uma tentativa de bloqueio sobre o arquivo, ele será manditory. Como uma questão prática, este impacto seria apenas uma ocasional programa como um depurador. Mas ls podem tratar este bit combinação diferente. Eu tenho visto esses dois tipos de ...

Links simbólicos têm evoluído ao longo dos anos. Na primeira, um link simbólico foi seguido apenas quando se abre um arquivo. Então:
toque Datafile
ln-s Datafile slink
chmod 700 slink
não proteger o arquivo chamado "Datafile". Este foi um problema de segurança. Hoje que "chmod 700 slink" vai alterar as permissões sobre dados. "chown fred Datafile" irá mudar também Datafile slink e deixe sozinho.

Links simbólicos Deve ter um Proprietário

Existe uma maneira de alterar o proprietário de uma ligação simbólica. É "chown-h slink". Isto irá mudar slink e deixar Datafile sozinho. A primeira razão para ligações simbólicas necessitam um proprietário é um recurso chamado "quotas". Contingentes permite a administração de sistemas para limitar o espaço em disco utilizado por um usuário. Um link simbólico consome uma pequena quantidade de recursos o disco que deve ser cobrado para o usuário apropriado. Temos agora uma segunda razão: pegajosas diretórios. Precisamos de saber quem pode remover um link simbólico de um diretório pegajosas.

Além de um proprietário, Posix exige que tenham uma ligação simbólica tamanho. Isso é tudo o que você pode depender. Links simbólicos pode mesmo não ter qualquer permissão bits.

Permissão Bits são exigidos por Posix devem ser ignorados

No Solaris e Linux, recém-criado links simbólicos são 777 e não é afetado por esse umask. Eu não poderia não encontrar nenhuma maneira de transformar os bits desligados. Em HP-UX, links simbólicos também são criados com o 777, mas não afectam este umask. Então:
umask 777
ln-s Datafile slink
Cria uma ligação simbólica com todos os bits desliga. Este não teve qualquer efeito sobre a todos os que eu poderia fazer com dados. E de ligação simbólica (com um modo de 0) aos diretórios também funcionou bem.

BSD Tem uma maneira de alterar a permissão Bits em um link simbólico

Os diferentes BSD distribuições têm todos um "chmod-h", que é como a necessária "chown-h". Utilizando este comando Eu testei links simbólicos no FreeBSD e descobri que eles ignoram permissão bits também. O "chmod-h" comando é executado usando uma lchmod () chamada de sistema. BSD (tem até uma lutimes () e uma chamada de sistema "touch-h" comando para invocá-la.) Até agora, tudo bem. Nada aqui é violar a Posix norma.

NetBSD maio a violar o Posix Norma

De acordo com o NetBSD symlink página man: "O readlink (2) chamada de sistema exige permissões de ler o link simbólico". readlink () é chamada de sistema utilizado por ls para visualizar o alvo de um link simbólico. Assim, com algo parecido com isto: aquele Datafile foi obtida com readlink (). Eu não tenho acesso a um sistema NetBSD para teste por isso não foi possível verificar isso.

HP-UX Transição Ligações

Quando reescreveu HP HP-UX System V conformes com a Versão 4, a localização dos lotes de arquivos alterados. Como um exemplo, o meu favorito reservatório movido a partir de / bin / ksh para / usr / bin / ksh. Algumas pessoas ainda usam / bin / ksh e que irá funcionar (por agora) por causa de uma ligação simbólica:
Como é que a HP ligar pegajosas pouco? O lchmod () chamada de sistema foi emprestado do BSD. Esta é uma característica dos indocumentados HP-UX. Da HP idéia é que eles podem ter a certeza de que um colante symlink não foi criado por qualquer usuário, pois os usuários não sabem sobre lchmod. Usando lchmod () para ligar o bit sticky não altera as propriedades do link de qualquer forma. A única diferença é que o da HP tl ferramentas estarão dispostos a operar no symlink.

Mas aqui é que o HP-UX faq tem a dizer: "Transição ligações são um pouco mais rapidamente, porque as ligadas-a filename é armazenada no nodo própria, em vez de usar uma unidade de atribuição para guardar a ligação. "Embora essa afirmação não é falsa, é terrivelmente enganosa. HP-UX simplesmente suporta fast links simbólicos. Se o ficheiro referenciado nome curto é suficiente, é armazenado diretamente na nodo. A transição ligações acontecer de ser suficientemente curto. Vi algumas pessoas usam lchmod () para ligar o bit sticky de um link em um esforço para acelerar as coisas. Não funciona assim.

Transição links estão começando a desaparecer. Pessoas que não tenham mudado de / bin / ksh para / usr / bin / ksh maio um dia chegar um rude surpresa. Abaixo estão alguns links ao site da HP.

Manter Transição Ligações
Transição Ligações Comandos (Desaprovada)
Ligações Transição (Desaprovada)

Nós discutimos como escrever permissão controla a capacidade de alterar os dados em um arquivo. Mas como sobre como mudar a permissão bits, o proprietário, o grupo, e mesmo a hora? Ninguém pode mudar qualquer coisa em um CD e um NFS servidor pode ignorar uma NFS cliente. Na discussão seguinte, vou assumir um local de leitura e escrita de ficheiros que o usuário chamado "root" tem especial adequado privilégios administrativos para o sistema de arquivo em questão.

chmod - Alterar as permissões do arquivo

Para alterar as permissões do arquivo de todo, você deve ser o proprietário do arquivo ou você deve ser o usuário root. O usuário root pode alterar qualquer permissão bit. Isto pode não ser verdade para o proprietário. A um pouco que o proprietário pode não ser capaz de ligar é o SGID bit.

Para ligar o bit, o proprietário deve ser um membro do grupo que o arquivo é pol Se essa restrição não foi no lugar, um usuário poderia simplesmente criar uma SGID programa dar-se o acesso aos arquivos controlados por grupos diferentes daqueles a qual ele pertence. Lembre-se que, como é referido acima, o SGID pouco tem sido frequentemente sobrecarregados em também ser utilizado para bloquear arquivo. Uma versão de Unix podem ou não permitir que um arquivo proprietário para ligar o SGID bit de um arquivo em um grupo diferente se não executar bit é definido.

Basta ligar executar um bit pode resultar na SUID e SGID bits que são habilitados (mesmo para o root). Este é um recurso de segurança para garantir que o utilizador pretende para o SUID e SGID bits a ser definido. O usuário pode mudá-los de volta em explicitamente. Ou o usuário pode simplesmente definir explicitamente todos os bits de uma só vez. Esteja ciente também de que a gravação de um arquivo pode, em algumas versões do Unix, limpar o SUID e SGID bits. Veja abaixo o efeito da alteração do proprietário ou do grupo de um arquivo.

chown - Mudando O Arquivo Proprietário

Originalmente, Unix permitido um arquivo proprietário a doar um arquivo. Um arquivo do proprietário poderá alterar o proprietário para outra pessoa. Não havia nenhuma maneira para um não-usuário root para desfazer esta operação. Quando dividida em uma Berkeley Unix / AT & T versões, a USG (Unix Support Group, uma parte da AT & T) versões do Unix tendem a herdar esse comportamento. Entretanto BSD (Berkeley Software Distribution, parte da Universidade da Califórnia, Berkeley) chown removido de raiz não-usuários. BSD tinha implementado disco quotas que poderia limitar a quantidade de espaço em disco que um usuário poderia ter em um sistema de ficheiros. Naughty usuários poderiam oferecer grandes arquivos para Sneek passado as quotas.

Hoje, não é fácil dizer se um país não pode chown root um arquivo. Muitas versões do Unix permite ambos comportamentos. HP-UX tem uma setprivgroup facilidade que pode controlar ou não membros de um grupo particular pode invocar chown. O Solaris tem um parâmetro mundial rstchown que pode ser configurado para permitir chown global. Definir este parâmetro também desabilita uma mudança de grupo limitação descrita abaixo (sem afetar o SGID limitações descritas acima). Recentes têm uma versão Linux CAP_CHOWN capacidade para controlar esta funcionalidade. Você terá que consultar a documentação para outras versões do Unix. E você terá que consultar o seu administrador do sistema para ver como seu sistema é configurado.

O padrão com a maioria dos SO's é para chown a ser limitada a apenas raiz. E há um consenso de que se deve manter esta forma de considerações de segurança. Se um usuário não-root não alterar o dono de um arquivo e executar qualquer bit é ligado, o SUID e SGID bits devem ser apuradas. Isso pode ou não acontecer com a raiz.

chown, chgrp - Alterando O Arquivo Grupo

O comando chown pode (com qualquer moderno, Posix versão compatível do Unix), também a tentativa de um grupo mudança. E há um comando chgrp. Ambos estes invocar o chown () chamada de sistema para alterar um grupo. O facto de um sistema comum chamada está envolvido ajuda a explicar porque é que algumas versões do SO conjuntamente valer ou relaxar restrições à raiz não-usuários de ambos os proprietário e grupo muda.

Um usuário não-root pode alterar o grupo de arquivo que ele é dono de um grupo do qual ele é um membro. Posix proíbe um não-usuário root mudem de arquivos um grupo a um grupo de que ele não é um membro. Mas alguns SO's levantar esta restrição se a restrição contra a alteração de um arquivo do proprietário tem sido levantada.

Se o grupo for alterado por um usuário não-root e executar uma ou bits são fixados, o SUID e SGID bits são apagadas.

touch - Alterar o arquivo timestamps

Quando o toque comando é usado para alterar a hora de um arquivo existente, que invoca tanto o antigo utime () ou o novo utimes () chamada de sistema. Para alterar a hora em um arquivo existente, você deve ser o arquivo ou a própria raiz. Além disso, você deve ter permissão de gravar o arquivo ou a raiz.