This is a "Dirty Dozen" of unsorted hints of things within this server. Written by (multitude?) of people: [mea] Matti Aarnio TOPICS: DATE: ---------------------------------------------------- ---------- What new user should do 910924/mea User shells and other related environment topics 911129/mea Getting file ownership with SUID program omi-file 950512/mea Joining to area-administrative group (join-group) 950512/mea About file permissions and groups 910920/mea Hiding things (files/symlinks) from the public 910920/mea Incoming directorys 920110/mea "message" -files for (ftp) CWD time use. 920110/mea Non-anonymous ftp-only accounts 920224/mea ---------------------------------------------------- ---------- PROLOG: These articles have been written when a definite need has arisen for them, and naturally they do NOT cover EVERYTHING. Ask for more info, write your own documents to be included here, etc. -> mea,hks What new user should do: - Read thru these /ftp/staff-docs (~ftp/staff-docs) files - Join (by him-/herself) mailinglists for staff (maints), and his/her interest area (and maybe ask for creation of another such list) Mail mailserver@lists.funet.fi Subject: This text comes back with prefix "Re:" ; If you are finnish user, ask help in finnish apua ; othervice as usual.. help ; Read thru what returned text tells you, and proceed to ; learn more about lists, and their subscribing method. subscribe maints Own Name subscribe ftp-reports Own Name - Not to be too shy/proud to ask for advice if something isn't covered by these instructions. (System maintainers may assume something so implicitely, that we don't write it down at all..) - However: User should learn his/her first UNIX elsewere, this isn't for teaching UNIX as much as for doing work.. (Work ? ... ;-) ) 910924/mea 940327/mea Getting file ownership with SUID program omi-file: /usr/local/bin/omi-file [-d] [-g group] [-m mode] [-o owner] filenames If users permissions match those listed in programs database (Quick help and references: omi-file w/o any arguments.) said user is allowed to change file ownership, group, and permissions. This can be done to multiple files at same time. If file to be modified (permissions modified) resides in a directory which user owns, user has permission to do anything (s)he wishes to that file. (Unless file has multiple hard links, in which case omi-file trusts no-one to touch it..) To acquire AREA-ADM -group for some particular area, see following topic about join-group. Occasionally it seem to bug. Don't know for sure... Bugreports -> mea@nic.funet.fi 910920/mea 950512/mea Joining to area-administrative group (join-group) For an example you want to join msdos-adm, issue command: join-group msdos-adm Local file /l/etc/join-group.dat controls what groups can be joined. There is NO command to leave a group, only system managers can do that cleanup. Joining a group causes automatically a "subscription" of similarly named email-list (actually the /etc/group -file is used on list alias expansion.) IF YOU JOIN TOO MANY GROUPS, YOU WILL AT FIRST LOOSE NFS-ACCESS TO ALEX-SERVER (NFS becomes upset when user has more than 16 groups.) 950512/mea About file permissions and groups: Suggested setup: directories permission 2775, group AREA-adm files permission 444, group AREA-adm* Directories should have permission 775 with group FTP, unless you want some privacy within your directory. With this setup anybody belonging to same group can make modifications in that directory, but not overwrite files while those file could still have your identity in them (misleading information). Directory permission 2000 is so called "BSD directory sematics", and is very usefull, as then per default files come in same GROUP as directory has. (Default is to create files with users effective group id.) With above-mentioned setup actual FILES can have permission 444, or 644. Now file owner STAYS (subject to omi-file usage) the same over its whole life, even when new copy is wanted to store on top of it... Old must be deleted before. Previously dirs had 775 with group FTP, and files 664 with group FTP. Don't use it, unless you have a reason. Note: Permission bit 2000 is a bit compicated to set: chmod g+s dir.name You can't do it with "chmod 2775 dir.name" -command! (This is documented in SunOS `man 1 chmod') (You can think of use for permission bit 1000 - directory sticky-bit, but I don't know if it is really worth it. Maybe ?) 910920/mea Hiding things (files/symlinks) from the public: You can hide files from public with a few methods: - Permission where global-read is missing (file and dir) - .ignored.names -- a list of files that are NOT allowed to be listed, but can be accessed (modulo tight protection). This MUST be sorted into ascending ASCII order. See /ftp/.ignored.names for an example. Permission: 644 -- anonymous user must be able to read it. - .recursion.ignored.names -- Alike, but effective only when ls -R is done. Example: /pub/gnu/.recursion.ignored.names Permission: 644 -- anonymous user must be able to read it. - .links.as.reals -flag file. Its existance (length 0) turns all symlinks into hard links in directory listing. It may have selected symlinks listed, and then those can be presented as hard links, while rest are presented as symlinks. Possible content lines must be sorted into ascending ascii order, and if it has contents, permission 644 is preferred. (Othervice 000 is fine.) 910920/mea Incoming directorys File submission directorys should have protection 777, or maybe 2777 (BSD semantics), in both cases ftp server will make sure nobody can read out files before they have been processed by administrators. That is: Using protection 733 (rwx-wx-wx) is NOT NEEDED here at the Funic, because our server has BETTER methods of enforcing file moderation before it is open for clients to access. It is NOT considered a good practice to just alter protections into that of the open file, and let the file be still in the "incoming" directory. Files should ALWAYS be checked against package errors, and viruses/whatever before they are made publically available. Maintain our reputation, check before make available. * Every upload is redistered by the ftp server. The system * * sends a daily report listing some statistics, and SAME * * PERIOD UPLOADS into the mailing list "usagereports". * * (Subscribe via mailserver!) * On EVERY file there should be a record on who uploaded the material into the Funic. At present there isn't, but it SHOULD be made a standard practice that every published upload requires a letter FROM the moderator to the uploader be gotten a sensible answer which states what the file is, and what is its copyright status. System sends once in a night a report of uploaded material to the mailserver's UPLOADREPORT -list. Those reports are also archived at the /usr/local/log/upload-notes/daily file, where from they are also available later. 911125/mea 911129/mea 920110/mea "message" -files for (ftp) CWD time use. When any directory has a globally readable file with name "message", that file is printed verbatim to the command connection reply stream (as "221-"-replies) before giving the actual final "221 "-reply. An example of this file and its use: /pub/localsrc/message ftp nic.funet.fi anonymous demo@nic.funet.fi cd /pub/localsrc 221-..... .... 221 CWD command successfull. etc.. 920110/mea Non-anonymous ftp-only accounts. Such accounts which have normal user priviledges (that is, they are not subject to flow control), but are only for FTP (no telnet login, etc.) are quite easy to produce: Account will be treated with chroot(), thus it is confined into its own home directory alike anonymous-ftp is. Steps: - create an account (say: "linux2") in normal way into the /etc/passwd -file, but give it shell: /usr/local/lib/ftp-only-shell DO NOT DO /usr/local/etc/adduser UNDER ANY CIRCUMSTANCES! - Add the account into /etc/ftpusers: +linux2 For user xxx@yyy for mirroring the archive (That is, "+" in front of the name.) - Have its home directory to point to "/ftp" (same as with "ftp" account.) - Add an alias into /etc/aliases for that account which points to its responsible owner. Limits: - Unlimited retrieve capability. - Same rules regarding file store as normal anonymous. - Not for interactive (telnet) login. Only file transfer. - chroot() into $HOME of the account. 920224/mea