as permissões nos arquivos ftp'd parecem não corresponder a umask

Question

Eu li várias postagens indicando que o ftp respeita o umask do usuário. Eu não vejo que seja esse o caso. isso é o que acontece no meu servidor X quando transfiro um arquivo do SystemX para o SystemX. O SystemX é um sistema Solaris, minha umask é 002, a umask padrão em /etc/profile também é 002. Abaixo estão os resultados. As duas perguntas são: por que o arquivo ftp'd não respeita minha umask e de onde ele está realmente obtendo as configurações?

**SystemX:/home<username>: umask
02
SystemX:/home<username>: grep umask /etc/profile
umask 02
SystemX:/home<username>: touch junk
SystemX:/home<username>: ls -l junk
-rw-rw-r--   1 <username>  infadev        0 Jan  4 16:24 junk
SystemX:/home<username>: ftp SystemX
Connected to SystemX.
220 SystemX FTP server ready.
Name (SystemX:<username>): <username>
331 Password required for <username>.
Password:
230 User <username> logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> put junk junk.out
200 PORT command successful.
150 Opening BINARY mode data connection for junk.out.
226 Transfer complete.
ftp> bye
221-You have transferred 0 bytes in 1 files.
221-Total traffic for this session was 383 bytes in 1 transfers.
221-Thank you for using the FTP service on SystemX.
221 Goodbye.
SystemX:/home<username>: ls -l junk*
-rw-rw-r--   1 <username>  infadev        0 Jan  4 16:24 junk
-rw-r--r--   1 <username>  infadev        0 Jan  4 16:24 junk.out

    

Answer 1

Quando você usa colocar em ftp , é o servidor que determina as permissões do arquivo enviado.

Supondo que você esteja usando o servidor FTP do Solaris (e não algum aplicativo de terceiros), as informações estão em ftpaccess (4) , que descreve /etc/ftpd/ftpaccess

Essas configurações são relevantes para os arquivos enviados (eles são independentes das permissões cliente ):

defumask umask class

Set the umask applied to files created by the FTP server if the remote user is a member of the named class. If class is not specified, then use the umask as the default for classes that do not have one specified. The mode of files created may be specified by using the upload directive.

upload [absolute|relative] [class=classname]... [-] root-dir dirglob yes|no owner group mode [dirs|nodirs] [d_mode]

Define a directory with dirglob that permits or denies uploads. If it does permit uploads, all newly created files is owned by owner and group and has their permissions set according to mode. Existing files that are overwritten retains their original ownership and permissions. Directories are matched on a best-match basis. For example:

upload /var/ftp * no
upload /var/ftp /incoming yes ftp daemon 0666
upload /var/ftp /incoming/gifs yes jlc guest 0600 nodirs

would only allow uploads into /incoming and /incoming/gifs. Files that were uploaded to /incoming are owned by ftp/daemon and have permissions of 0666. Files uploaded to /incoming/gifs are owned by jlc/guest and have permissions of 0600. The optional dirs and nodirs keywords can be specified to allow or disallow the creation of new subdirectories using the mkdir command. If the upload command is used, directory creation is allowed by default. To turn it off by default, you must specify a user, group and mode followed by the nodirs keyword as the first line where the upload command is used in this file. If directories are permitted, the optional d_mode determines the permissions for a newly created directory. If d_mode is omitted, the permissions are inferred from mode. The permissions are 0777 if mode is also omitted. The upload keyword only applies to users who have a home directory of root-dir. root-dir may be specified as * to match any home directory. The owner or group may each be specified as *, in which case any uploaded files or directories are created with the ownership of the directory in which they are created. The optional first parameter selects whether root-dir names are interpreted as absolute or relative to the current chroot'd environment. The default is to interpret root-dir names as absolute. You can specify any number of class=classname restrictions. If any are specified, this upload clause only takes effect if the current user is a member of one of the classes.

In the absence of any matching upload clause, real and guest users can upload files and make directories, but anonymous users cannot. The mode of uploaded files is 0666. For created directories, the mode is 0777. Both modes are modified by the current umask setting.

Bastante prolixo, mas essencialmente dizendo:

• as permissões padrão dos arquivos enviados são mais frouxas do que as que você vê e
• defumask permite ao administrador reduzir essas permissões globalmente e
• upload permite ao administrador ajustar as coisas.

Na prática, a maioria dos administradores provavelmente define defumask .

As permissões dos arquivos enviados não dependem da sua configuração umask no shell fora do cliente ftp . A página de manual do Solaris ftpaccess implica (consulte a seção sobre Recursos de Permissão ) que os clientes podem especificar um umask, mas seu cliente não lista isso como um comando.

Mesmo com as configurações documentadas, alguns administradores encontram peculiaridades, por exemplo,

• Defumask e diretiva de upload no ftp
• Solaris ftp umask - / etc / ftpd / ftpaccess