Solaris ftp umask - /etc/ftpd/ftpaccess

How to setup umask for ftp users on Solaris.

Here is the official doc page to setup ftpaccess configuration from Oracle 
http://docs.oracle.com/cd/E23823_01/html/816-5174/ftpaccess-4.html#REFMAN4ftpaccess-4

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 optionald_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 groupmay 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  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.

Which basically tells you - figure it out :-)

Our requirement is to upload files and directories as user1 with permission 777 so any normal user can remove the uploaded directories.

After spending hours with defumask and umask syntax, I figured out that the secret sauce is in the upload.

edit /etc/ftpd/ftpaccess as below

upload  /mft/user1 /mft/user1  yes user1 group1 0777 dirs 0777
upload  /mft/user1 /mft/user1/*  yes user1 group1 0777 dirs 0777
upload  /mft/user1 /mft/user1/*/*  yes user1 group1 0777 dirs 0777


if you  are uploading a structure like folder1/folder2/folder3 under /mft/user1

You would need all 3 lines to make all the folder1/folder2/folder3 files/directories under /mft/user1 with 777

:-( 
i know

Runtime linker error ld.so.1

Here is an error example:
bash-3.2# /usr/local/GraphicsMagick/bin/gm display
ld.so.1: gm: fatal: libfreetype.so.6: open failed: No such file or directory

What is this problem means: This is runtime linker error which tells us that this application/binary consists of more than one shared dynamic objects dependencies. ld.so is trying to link all the dependencies and not able to find few shared ojbects.

The environment variable LD_LIBRARY_PATH can be used to indicate directories to be searched before the default directories

Try ldd to print all the shared library dependencies for this binary.
bash-3.2# ldd /usr/local/GraphicsMagick/bin/gm

libtiff.so.3 => /usr/lib/libtiff.so.3
libfreetype.so.6 => (file not found)                                       <==(file not found error)
libjpeg.so.9 => (file not found)                                             <==(file not found error)
libpng12.so.0 => /usr/lib/libpng12.so.0
libXext.so.0 => /usr/lib/libXext.so.0
libSM.so.6 => /usr/lib/libSM.so.6
libICE.so.6 => /usr/lib/libICE.so.6
libX11.so.4 => /usr/lib/libX11.so.4
libsocket.so.1 => /lib/libsocket.so.1
libnsl.so.1 => /lib/libnsl.so.1
libbz2.so => /usr/local/lib/libbz2.so
libxml2.so.2 => /usr/lib/libxml2.so.2
libz.so => /usr/local/lib/libz.so
libm.so.2 => /lib/libm.so.2
libpthread.so.1 => /lib/libpthread.so.1
libc.so.1 => /lib/libc.so.1
libz.so.1 => /usr/local/lib/libz.so.1
libz.so.1 (SUNW_1.1) => (version not found)
libz.so.1 (SUNW_1.1) => (version not found)
libz.so.1 (SUNW_1.1) => (version not found)
libdl.so.1 => /lib/libdl.so.1
libmp.so.2 => /lib/libmp.so.2
libmd.so.1 => /lib/libmd.so.1
libscf.so.1 => /lib/libscf.so.1
libgcc_s.so.1 => /opt/artesia68/lib/libgcc_s.so.1
libz.so.1 (SUNW_1.1) => (version not found)
libdoor.so.1 => /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 => /lib/libgen.so.1
/lib/libm/libm_hwcap1.so.2
/platform/sun4v/lib/libc_psr.so.1
/platform/sun4v/lib/libmd_psr.so.1

Check LD_LIBRARY_PATH
echo $LD_LIBRARY_PATH /opt/game/jboss/lib: /opt/game/java/lib: /opt/game/lib: /opt/game/lib/inso: /opt/game/java/jre/lib/sparc/client: /opt/game/java/jre/lib/sparc: /opt/game/ImageMagick-6.4.4/lib: /usr/sfw/lib/sparcv9

Find the missing library path
bash-3.2# ls -l /usr/sfw/lib/libfreetype.so.6
-rwxr-xr-x 1 root bin 882032 Jun 6 2012 /usr/sfw/lib/libfreetype.so.6

By default For 32-bit objects are /lib followed by /usr/lib.
For 64-bit objects, the defaults are /lib/64 followed by /usr/lib/64

Here in this example the 32-bit path for libfreetype.so.6 is not defined which should be /usr/sfw/lib/ instead of /usr/sfw/lib/sparcv9

Point/Link the required /usr/sfw/lib/libfreetype.so.6 under /usr/lib
bash-3.2# ln -s /usr/sfw/lib/libfreetype.so.6 /usr/lib/libfreetype.so.6

Point/Link
bash-3.2# ln -s /usr/local/lib/libjpeg.so.9.0.0 /usr/lib/libjpeg.so.9

X11 doesn't work with sudo su -

Here is the situation:

login as: pkg
Using keyboard-interactive authentication.
Password:
Last login: Tue Jan  7 22:02:07 2014 from l2554
Kickstarted on 2012-10-19
/usr/bin/xauth:  creating new authority file /home/pkg/.Xauthority

[pkg@mdc3 ~]$xterm - works
[pkg@mdc3 ~]$sudo su -

[root@mdc3 ]# xterm - doesn't work
PuTTY X11 proxy: wrong authorisation protocol attemptedWarning: This program is an suid-root program or is being run by the root user. The full text of the error or warning message cannot be safely formatted
in this environment. You may get a more descriptive message by running the
program as a non-root user or by removing the suid bit on the executable.
xterm Xt error: Can't open display: %s

Here is what you have to do
su - pkg -c "xauth list"  | xargs -n 3 xauth add


Basically we have to add the xauth created by user "pkg" to this new user "root"

[pkg@mdc3vr1138 ~]$ xauth list
mdc3vr1138/unix:10  MIT-MAGIC-COOKIE-1  d9241397a36b9ecc2cb03b07addf4008

[root@mdc3vr1138 ~]# xauth add mdc3vr1138/unix:10  MIT-MAGIC-COOKIE-1  d9241397a36b9ecc2cb03b07addf4008