2

I've read several postings indicating that ftp respects the user's umask. I don't see that that is the case. this is what happens on my server X when I FTP a file from SystemX, to SystemX. SystemX is a Solaris system, my umask is 002, the default umask in /etc/profile is also 002. Below are the results. The two questions are, why does the ftp'd file not respect my umask, and where is it actually getting it's settings from?

**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
  • 2
    The ftp server maintains its own umask setting. Some ftp server implementations are configurable. – Thomas Dickey Jan 5 '16 at 0:35
  • @ThomasDickey, what the server wants to do has no relevance to the client getting the files. – vonbrand Jan 5 '16 at 1:08
  • The command that I see in the example is put, not get. – Thomas Dickey Jan 5 '16 at 1:10
0

When you use put in ftp, it is the server which determines the permissions of the uploaded file.

Assuming you are using Solaris' ftp server (and not some third-party application), the information is in ftpaccess(4), which describes /etc/ftpd/ftpaccess

These settings are relevant for uploaded files (these are independent of the client permissions):

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.

Rather wordy, but essentially saying:

  • the default permissions on uploaded files are more lax than what you see, and
  • defumask allows the administrator to reduce those permissions globally, and
  • upload allows the administrator to fine-tune things.

In practice, most administrators probably just set defumask.

The permissions on uploaded files do not depend on your umask setting in the shell outside the ftp client. The Solaris ftpaccess manual page implies (see its section on Permission Capabilities) that clients might be able to specify a umask, but its client does not list that as a command.

Even with the documented settings, some administrators find quirks, e.g.,

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.