VINES file services let DOS, Windows, OS/2, and Macintosh users share and use information on the fixed disks in a Banyan server. This chapter assumes that you understand the basics of DOS, Windows 96, Windows NT, and Macintosh file systems. When you finish reading this chapter, you should understand how VINES file services work and how to use them.
Users of a VINES file service can perform all the file-related tasks they normally do, such as editing files, running executable files, or renaming files. To a user, a network disk under the control of a file service seems to be a local fixed disk drive, such as drive C for a DOS user or a hard disk for a Macintosh user.
The following four elements work together to provide orderly and secure file sharing for network users:
The file volume, a storage area on a server disk Network software in a user's DOS, Windows, or OS/2 workstation that redirects file operations to network file volumes Software that runs on the server and handles requests to read from and write to files on the server's file volume Management programs (StreetTalk Explorer, MSERVICE, SETDRIVE, and SETARL) that you use to create, maintain, and protect the file volume on the network
To understand the way file services work, you must understand the differences between network file volumes and local disk drives. You must then learn how to use directories on network file volumes.
Network File Volumes and Local Disk Drives
Using file volumes on the network is similar to using local fixed disks, but there are some differences. This section explains the most important differences.
Drive Designators
A major difference between file volumes and local disk drives for DOS, Windows, and OS/2 users is how drive designators, such as A:, are used. A drive designator on a stand-alone workstation refers to a physical disk drive. For example, A: refers to whatever diskette is in the first floppy disk drive, and C: refers to the first fixed disk.
On workstations connected to the network, drive designators refer to a network file volume, not a physical disk drive. You set a drive designator to refer to a file volume. For example, B: refers to the second floppy drive in a workstation. B: can also mean any network file volume that you designate as B:.
For DOS, Windows, and OS/2 users, the letters A through Z are available to set to network file volumes. For example, if you set drive E to the file service SharedFiles@Mkt@WCTUS, all operations involving drive E use files on that volume. Each time a user issues a COPY command or other file input or output command involving drive E, network software on the workstation redirects the operation to that VINES file volume.
The terms network drive, file service, and file volume can be used interchangeably. The same StreetTalk name always identifies a file volume and a file service.
The VINES file volume icon on the Macintosh desktop identifies network file volumes. The name of the file volume is under the icon.
File Volume Size
Another important difference between file volumes and local disk drives is size. The maximum size of the disk or diskette determines the size of a workstation file volume. A VINES file volume, in contrast, is an area on a server disk. It grows dynamically as files are added or expanded. A server disk can contain several file volumes. Each file volume is controlled by one Banyan file service and has a network drive letter or icon associated with it.
Accessing a Workstation Disk Drive
A user logged into a VINES workstation cannot use Banyan software to access information stored locally on another workstation. A local drive does not have a StreetTalk name, is not managed by a file service, and cannot be accessed by another workstation in the network.
LANs operate faster than DOS, Windows, and OS/2 workstation disk drives. Users should notice no delay in the response of workstations when they start using network drives.
Using Directories on Network File Volumes
To make using directories easy for users, network file volumes are organized like the file systems of their workstations. For DOS, Windows, and OS/2 users, network file volumes use the DOS, Windows, and OS/2 directory structure. Within that structure, each VINES file volume has these parts:
One root (top-level) directory A number of subdirectories that you create as needed
For Macintosh users, network file volumes consist of file folders. In these environments, both the top-level directory and all subdirectories can contain other subdirectories.
With VINES file volumes, users can assign a drive designator to a file volume or to a directory within a volume. There are many ways to use drive designators that are set to network file volumes and directories. Each user can have several drives set to network file volumes.
A VINES file volume is not a physical device attached to a workstation. You therefore have more flexibility for setting drive designators to network drives and for using directories within those drives.
Example Entering Directory Commands
The directory commands that you use on local drives work the same way on network drives.
Assume that drive E is set to the volume SharedFiles@Mkt@WCTUS. If the DOS prompt is E: and you issue the command CD SUBDIR2, that directory becomes the current one for drive E.
Example Setting Drive Designators
You can associate more than one drive designator with the same file volume. Within that volume, both designators are set to different directories when the CD command is entered in a user profile.
In addition to drive E, drive F is associated with the file volume SharedFiles@Mkt@WCTUS. E is set to the APPS subdirectory, and F is set to the top-level directory as shown in Figure 9-2.
All operations involving drive F use files on the top-level directory of that file volume.
Now you have set two different drive letters, E and F, to the same file volume, but to two different directories. This kind of setup is useful for application programs that do not allow you to change directories within the program or do not recognize subdirectories.
Example Designating the Top-level Directory
VINES also lets you designate a subdirectory as the top-level directory of a file service.
In this example, drive F is associated with a subdirectory of the file volume SharedFiles@Sales@WCTUS. In users' profiles, the SETDRIVE command is issued with the argument /ROOT:\public. Set access rights on the file volume so users cannot open or create files in the top-level directory. Then, all operations involving drive F are restricted to the F:public subdirectory of that file volume.
When users log in, F: is their drive designator but F:\public is their top-level directory. Users cannot see files in the top-level directory or go to other subdirectories from F:.
Applications that must write to files in the top-level directory can write files in the F:\public subdirectory.
OS/2 File System and Extended Attribute Support
OS/2 users can store files in the same VINES file volumes as DOS users. VINES supports OS/2 extended file attributes. Attributes control what kind of operations can be performed on a file.
Extended attributes are part of the OS/2 FAT (File Allocation Table) and OS/2 HPFS (High Performance File System) file systems. OS/2 extended attribute support has no effect on DOS users.
For OS/2 users who use the DOS-compatible FAT file system, files appear as DOS files do. For OS/2 users who use HPFS, VINES file volumes accept only filenames that have up to eight characters plus a three-character extension.
Setting Up a Directory Hierarchy
You can set up VINES file volumes in many ways to meet the needs of users.
Here are some ideas on how to set up a directory hierarchy on a file volume:
Keep files out of the top-level directory to make your file volumes easier to manage. Put only subdirectories for users, applications, and groups in the top-level directory. Store the information for a particular project in one file volume and create subdirectories for different kinds of project information. Set up a file volume for each group on the network. Create subdirectories for users or for document types, depending on how the users in the group work together. Users can create their own subdirectories for different projects, applications, and so on.
The VINES file system is designed to support the following file systems:
DOS and OS/2 standard File Allocation Table (FAT) Windows 95 and Windows NT long file names (LFN) Macintosh AppleTalk Filing Protocol (AFP) UNIX file system
Each of these file systems has rules for creating file names. For example, if a file is created at a Macintosh workstation with a Macintosh file name but stored on a native VINES server, the file is stored with its Macintosh name and in Macintosh format. If users or applications are going to share files created under different systems, you must understand how VINES handles these different naming conventions.
UNIX
The UNIX file system on a native VINES server is accessible through Enhanced UNIX Access at the server console and to applications written with the Banyan Applications Toolkit.
If your network consists of only one type of workstation or the different types of workstations are isolated from one another, you can skip the information presented in this section.
Table 9-1 summarizes the rules of DOS, OS/2, and Macintosh and the following sections explain them.
Long File Names (LFN)
Native VINES 7.0 and greater and StreetTalk for Windows NT support long file names that can be created from Windows 95 and Windows NT or from an application running on a Windows 95 client workstation or a Windows NT client workstation that supports long file names. Long file names do not follow the DOS 8.3 format. Instead, a long file name can be a maximum of 255 characters and can include all valid characters defined for DOS 8.3 names (Table 9-1) plus the following characters:
Space , (comma) ; (semicolon) = (equals sign) [ ] (square brackets)
A user at a Windows 95 or Windows NT workstation can create a file with a long file name and store that file on a native VINES file service. Other users at a Windows 95 workstation or a Windows NT client workstations see that long file name. A DOS user will see an alias, a DOS 8.3 name that truncates the long file name and replaces the truncated characters with a tilde (~). An alias is generated any time a filename:
Is not 8.3 compliant Is not all upper case Contains characters not allowed in an 8.3 name
Case Insensitivity
Case insensitivity means that the file system does not make a distinction between upper- and lower-case characters. For example, the case insensitive file systems would see INTRO, Intro, and intro as the same file.
In addition, the case insensitive file systems handle the display of file names differently:
DOS lets you enter upper-case or lower-case letters. However, DOS converts and then displays any lower-case letters you enter as upper-case letters. For example, if you enter report.doc, DOS displays the name as REPORT.DOC. Windows NT lets you enter upper-case or lower-case letters and displays them as you entered them. For example, if you enter Report.doc, Windows NT displays the name as Report. doc. However, while Windows NT is case-aware, it is not case-sensitive. You cannot create another file named report.doc Macintosh also lets you enter file names using upper-case and lower-case letters, but preserves the case that you use. For example, if you enter Report, the file system displays the file name as Report.
Delimiters
The Macintosh operating system uses a colon as a delimiter between disk, folder, and file names. If you use two colons in a file name (for example, Acctg:Jan:Report), the operating system treats the text before the first colon (Acctg) as a disk name, the text between the two colons (Jan) as a folder name, and the text after the second colon (Report) as the file name.
DOS and OS/2 use the reverse backslash (\) as a delimiter in a pathname.
Illegal Characters in File Names
The illegal characters shown in Table 9-1 cannot be used in the file names of the file systems to which they apply. Some characters that are legal as delimiters (for example, colons in Macintosh pathnames) are illegal in file names.
Sharing Files with Different Formats
When users on different workstations want to access files controlled by a VINES file service, they associate a file volume with a drive on their workstations. For example, if a Macintosh user connected to a native VINES server and a DOS or Windows user want to share files on volume MktFiles@Mkt@WCTUS, the DOS or Windows user maps the drive and the Macintosh user mounts the file volume on the desktop. They use their respective workstation's mechanism (StreetTalk Explorer for Windows 95 or Windows NT, the SETDRIVE command for DOS and the Chooser for Macintosh). Both users can then share the same file volume, as in Figure 9-3.
However, to read and manipulate files created under different operating systems, users have to save files in a format compatible with their own file system or run a conversion utility on them. Conversion utilities strip and restore the appropriate codes for the application(s) and file systems. VINES does not translate one file format into another.
You must supply such a translation program (for example, MacLink®Plus/Translators) to your users. Some applications (for example, word processors) let you create a file in one format and save it in another.
Both an AFP service and a VINES file service must be running on a native VINES server that stores files that Macintosh users want to access.
Mapping DOS Extensions
Macintosh
Some utilities that support DOS and Macintosh file sharing associate DOS filename extensions with Macintosh file Creator and Type identifiers when files are created in the same application. The Creator is the application's source (for example, WordPerfect®) and Type is its format (for example, text).
Mapping DOS extensions to these Macintosh identifiers lets users create a file in the DOS version of an application, save the file in Macintosh format, and then click on the file's icon to open the file and launch its application on a Macintosh.
The VINES AppleTalk Filing Protocol (AFP) service lets you map a DOS extension to a Macintosh Type and Creator. It provides some typical application names that you can use. Many applications such as WordPerfect create files with you unique extensions (for example, .WPP for WordPerfect). You can associate this extension with a Type and Creator within the AFP service.
After you have created the mappings, refer your users to the VINES User's Guide for Macintosh for information on how to take advantage of them.
To share files users must also be aware of the different naming rules that the different operating systems use. These are explained in the following sections.
How VINES Handles Macintosh (AFP) Names
When a file is created from a Macintosh client and the Macintosh name is a legal DOS name, the Macintosh name and the DOS name are the same. (A DOS name is legal when it has eight characters, a three character extension, and no illegal characters.)
If a file is created with a Macintosh name that does not follow the DOS naming convention, a DOS name is created from the Macintosh name. The Macintosh name is truncated if it is too long, and any illegal characters are converted to legal characters. Spaces, which are legal, are converted to underscores to facilitate typing a DOS command.
Example Viewing Macintosh File Names from DOS
The DOS DIR command displays the Macintosh file name MacEquipment as !MACEQUI.PME. (The exclamation mark ! indicates that the name has been truncated or illegal characters were dropped.)
AFP does not rename the extension even if AFP was configured for icon/extension mapping.
If you anticipate that DOS users will access files created under Macintosh, instruct your Macintosh users to always create filenames that are legal in DOS and that have the proper DOS extension for the application.
All DOS names are legal under OS/2, but filenames that are created under OS/2 can be illegal for DOS and Macintosh users.
DOS and OS/2 follow the XOPEN computer industry standards. VINES conforms to these rules except when a file is created at a Macintosh workstation.
Under XOPEN rules, filenames are not truncated and illegal characters are not mapped to legal characters. Instead, if an OS/2 user creates a name that's long by DOS or Macintosh standards or has illegal Macintosh characters, the file does not appear in the directory of the file system whose rules were broken.
If a name is created on a workstation that is case-insensitive (for example, DOS), it appears in all lower case on workstation that is case-sensitive. If a name is created on a case-sensitive workstation, it appears in a case-insensitive workstation only if the name is all lower case.
The easiest way to minimize naming problems is to create names that follow the DOS and OS/2 FAT rules, that is, the naming conventions of the most restrictive file systems.
For more information on these naming rules see Managing VINES Services, VINES User's Guide for DOS and OS/2, and VINES User's Guide for Macintosh.
The VINES V commands let you display and manipulate long file names. The V commands are:
VDIR - Displays long and short file and directory names. VDIR works only on VINES file volumes.
VCOPY - Copies files and directories including Macintosh resource forks and data forks and OS/2 extended attributes. VCOPY can also copy access rights lists.
VRENAME - Changes names associated with a file. You can use VRENAME from a DOS, Windows, or OS/2 workstation to change the name of a Macintosh file as seen from a Macintosh workstation.
DOS and OS/2 users must use the VCOPY command when they copy Macintosh or OS/2 files from one VINES file volume to another. The DOS COPY command does not copy the resource and data forks associated with the Macintosh files.
These commands work only on network drives that are controlled by a VINES 5.xx or greater file service or a StreetTalk for Windows NT file service.
Users need the appropriate access rights before they can run the V commands. For example, VRENAME requires Write access to a file and its directory and VDIR requires Search access to directories. If users don't have the proper access, they receive an "access denied" error message when they run a V command. Access rights are described in a later section.
See the Command Reference, VINES User's Guide for DOS and OS/2, and Managing VINES Services for more information about these commands.
To create a file volume on the network, you add a file service name to StreetTalk, select a server and a disk on that server, and then start the service.
The name you give to a file service must be unique within its group. Create a name that describes the information handled by the file service or the users who use it, or that makes the service easy to recognize in some other way.
Follow these guidelines to make file services perform faster:
Select a server that is on the same LAN segment as users of the file volume, especially if the applications they use involve a lot of input and output. Create as few file services as possible. Put application programs in subdirectories rather than starting new file services. Select a disk that has room for expansion. Estimate the eventual size of the file volume and allow for growth. Put heavily used services on several disks to balance the load on the server disks. With native VINES, avoid using disk1 if possible, since that disk contains VINES system files and is heavily used. In a multi-server network, add the file service to a group that the server maintains. The file service should also reside on that server. This way, the service's StreetTalk location information and the service itself are in one place. Chapter 7 explains why a service and a group should be on the same server. If users access file services over serial lines or over slow-speed dial-in lines, monitor the memory usage on servers where the services reside. You may have to fine tune memory parameters (cache space and cache buffer size) or reconfigure your network to increase throughput between users and file services. For more information, see Monitoring and Optimizing Servers.
Network security is an important feature of VINES and one that you must consider as you plan how to use file services. VINES provides the following two features that help you control what happens to network files:
For each directory and file on the network, you can set up an access rights list (ARL) that protects them. For files on the network, attributes control how users or application programs can access file or directories.
The next sections describe VINES file security features to help you plan how to use them.
VINES uses an access rights list (ARL) to protect the contents of directories and files. An access rights list determines what operations users can perform on a file or directory. Just as you can limit the physical distribution of a diskette to protect the information on it, you can set an access rights list on a directory and files in the directory to protect all the information in them.
VINES provides ARLs for the DOS and OS/2 operating systems, which do not have their own ARL scheme, and extends Macintosh privileges from folders to files. Managing StreetTalk for Windows NT Services describes how ARLs are implemented on a Windows NT Server.
Components
An access rights list has a number of entries, each with two parts:
Identifiers that determine who can use a directory or file Rights associated with each identifier that describe how directories or files can be used
You can run StreetTalk Explorer or the SETARL program to set an access rights list for any directory or file in a file volume at any time.
The Banyan management program lets you manage the security of files and directories created under different operating systems. It also attempts to limit the ability of a user to circumvent the security settings of one operating system by accessing a file or directory from another operating system.
Identifiers
There are two kinds of identifiers: a primary list and an extended list. The primary list is always present and has three identifier types: Owner, Group, and World.
Owner - Every ARL must have an Owner. The Owner of the top-level directory is the user who created the file service. If that user creates subdirectories, the user is also the Owner of the subdirectories. An Owner cannot be a group, organization, or list. An Owner can transfer ownership to another user.
Group - The default is <any group>. You can change this to any StreetTalk group or list. The Group identifier is not restricted to a StreetTalk group, but it is recommended that you enter a StreetTalk group name and avoid entering a list.
World - A user who is not an Owner or a member of Group belongs to World. World is the StreetTalk *@*@* template. This entry cannot be changed.
Macintosh
Users logging in as Guest from a Macintosh will have the access rights assigned to World. In Macintosh terminology, World is called Everyone.
The Owner, Group, and World identifier always has a StreetTalk name associated with it. The StreetTalk name must be a full user name or nickname, group name, organization name, or a list.
An ARL on the top-level directory of a VINES volume makes the directory accessible when it is first created.
Extended List Identifier
You can enter a maximum of five StreetTalk names in an extended list. Extended lists are optional and can include:
A user's name Lists of StreetTalk users Other StreetTalk groups in your organization Other StreetTalk organizations on your network
You give each user in the extended list a unique combination of rights and you assign Maximum Rights. Maximum Rights are the most rights that anyone in the extended list can have. The Maximum Rights always override the rights that you might assign to the Group and World entries in the primary list. They can be more or less restrictive than the rights assigned in the primary list.
You can use extended list identifiers to fine tune the primary list. For example, by adding a temporary employee in an accounting department to an extended list you can restrict the access of that user to files and directories that all members of the accounting group normally access.
Order of Precedence
When a user attempts to access a directory or file, the file service looks through the access rights list of the primary and extended lists and finds the user's name in some form.
VINES checks names in the following order:
1. Owner
2. User name in the extended list
3. Group
4. Groups or lists in the extended list
5. Organizations in the extended list
6. World
If a user belongs to Group, World, and is on the extended list, the rights of the extended list supersede those of Group and World. If Owner is on both the primary and extended lists, Owner's primary list rights override the rights granted by membership in the extended list.
Rights Assignable to Directories
DOS and OS/2
Members of Owner, Group, World, and extended lists can be assigned one or more of the following rights to a directory:
Control (C) - Lets a user change the access rights list. Control access does not give the user any other access rights over the directory.
Search (S) - Lets a user search for all file and directory names contained in a directory. Opening a file requires this right. Without Search access users can't do anything with the files and subdirectories contained in a directory.
Read (R) - Lets a user see all the file and directory names contained in the directory. Typically, you use Read access when you want information to be shared and also want to keep it stable.
Write (W) - Lets users with Search access create, change the attributes, delete (provided users also have Delete access), and rename files and directories contained in the directory. Without Search access users can create a drop box, directory where they can put files, but not access them.
Delete (D) - Lets users delete files or directories when combined with Search.
Access rights within VINES follow the hierarchy of the DOS tree structure. To access any subdirectory, a user must have at least Search access to all parent directories.
Access rights to directories are not cumulative. For example, a user who has Control access to a directory does not have Search, Read, or Write access.
Rights Assigned to Files
DOS and OS/2
Members of Owner, Group, World, and extended lists can be assigned one or more of the following rights to a file:
Control (C) - Lets a user change the ownership, access rights, and group identifiers.
Execute (E) - Lets a user execute the file, for example, to use the file as a program file.
Read (R) - Lets a user open the file for reading.
Write (W) - Lets a user open the file for writing.
Access rights to files are not cumulative. For example, a user who has Control access to a file it does not have Read, Write, and Execute access.
Rights Assigned to New Directories and Files
Under VINES, subdirectories always inherit the access rights list from the parent directory.
OS/2
When a data file is created, the primary and extended list of identifiers is copied from the parent ARL to the new file. You set the rights that each identifier has in the ARL for New Files. The ARL for New Files governs the rights for any new files created in the directory. A later section describes this ARL.
Access Rights of AdminList and Group Members
When a file service is created, the creator has all rights. Members of the AdminList of the group to which the service belongs have Control (C) access rights to the directory and any new files created in the directory. If you don't want a user on the AdminList to have Control access, remove that user's name from the AdminList. Remember that Control access lets you change other access rights.
Other members of the group do not have any access rights initially. You must give group members S, R, W, and D access rights on the ARLs for the parent directory and R, W, and E access to new files so that they can work in their home directories. The precise ARLs you assign depend on the degree of security you implement.
For more information on this, see Managing Users and StreetTalk.
To set access rights on directories and files you run the SETARL program.
StreetTalk Explorer and the SETARL program let you modify the identifiers and access rights for the directory and for new files created under DOS, Windows, or OS/2 in the directory. The dialog boxes and program screens are in the form of check boxes or a matrix as shown in Figure 9-4. The matrix shows you the VINES view - how VINES assigns access rights to DOS and OS/2 files and directories.
If you are the Owner, are in the AdminList, or have Control access, you can change the owner's name, the group name, and add and delete names to the extended list.
The access rights shown in Figure 9-4 are the default rights of the Owner who created the file service. The Owner is a user (Smith). Smith has all access rights. The Group members are in Smith's group (PAY). The Pay Group and users in the *@* template (World) do not have any rights. When you add members to the extended list, they do not have any rights (as indicated by all minus signs) until you change them.
When you run a Banyan management program and specify a file name (for example, SETARL RESUME.DOC), you can modify the ARLs of each file. These ARLs are also in the form of a matrix. See Figure 9-5.
By default, the Owner has the rights specified in the "ARL for New Files" of the parent directory. In this example, the Owner, who created the file service, has all rights and the Group and World users have no rights to the file. Members of the extended list have all rights.
When you plan access rights, consider these suggestions:
For the strictest security, only a member of an AdminList or Owner of a directory or file should have rights to it. Members of the Group and World identifiers should have no access rights. Members of extended lists should only be users and not lists, groups, or organizations. When a files service is started, only the Owner and AdminList will have access to its directories and files. Don't change the default.
VINES defaults provide for strict security on files and directories unless you add any names to the extended list or include a large number of names on your AdminList.
For medium security, give Owner all rights and members of the Group identifier all rights except Control (C) and Delete (D) access. Members of the World identifier should have no access rights. Restrict the Group identifier to StreetTalk groups. For loose security, give Owner and Group all rights. Give the World identifier Search (S) and Read (R) rights. The Group identifier may include lists as well as StreetTalk groups. To speed the execution of file operations, extended list entries should not be StreetTalk lists that have other lists. "Nested" lists impair performance.
StreetTalk lists can help you set the same level of access rights for selected users in one group or for users in different groups.
The Chicago (USA) office of the WCT corporation has two file services, one stores payroll records and the other stores sales data. The security settings on the payroll information is stricter than on the sales data. WCT lets users in branch offices access sales but not payroll data.
WCT uses an extended list to let the sales groups in the branch offices read the sales database in Chicago.
The ARLs on the Payroll file service (Pay) are shown in Figure 9-6.
Group has SEARCH, READ, and WRITE access to directories.
No entries on the Extended List.
The ARLs on the Sales file service are shown in Figure 9-7.
If WCT needed to put more than five entries on the Extended List, it could create a list and include the list as an entry. However, as noted previously, "nested" lists are not recommended.
After you understand how access rights work, you can use the VINES Access Rights Worksheet, illustrated in Figure 9-8, to plan security for directories and files. Add a plus (+) or minus (-) in each cell.
The worksheet is in Appendix A.
Sharing Files in a Mixed Environment
To manage a network, you must understand how application programs and DOS, Windows, or OS/2 deal with files that users share. The sections that follow discuss these issues.
The information that follows is only relevant if you expect that DOS (or OS/2) users and Macintosh users will share files and that securing these files is important.
When a Macintosh user creates a folder, the Macintosh operating system imposes its own security model on it. Macintosh supports access rights for folders but not for files. When Macintosh files are stored on a Banyan network, VINES replicates the Macintosh scheme for folders and extends it to files. That extension is referred to here as the VINES-Macintosh view.
VINES lets you set access rights on files within folders as it does for DOS, Windows, or OS/2 files within a directory. Initially, the files you create inherit the access rights of the parent folder, but you can later change the file access rights.
Macintosh Privileges
In the Macintosh view, the ARL of a folder contains the following three access rights (or privileges in Macintosh terminology):
See Folders - Lets a user open a folder and see its contents.
See Files - Lets a user read the files in a folder. Users can open the files for reading, but they cannot make any changes.
Make Changes - If you assign only this privilege, you create a drop box, a folder in which users can put files but cannot access them. If you assign Make Changes and See Files, users can create, delete, rename, and change attributes of files in a folder. The combination of Make Changes and See Folders lets users modify folders.
These access rights are not cumulative. For example, granting Make Changes access to a folder does not grant See Files and See Folders access.
The VINES-Macintosh view extends See Files and Make Changes privileges to files.
The VINES SETARL program run from DOS or OS/2 lets you see how the rights for new folders and files look under the VINES and Macintosh views. From a Macintosh, the Set Access Rights application, which is part of the VINES Utilities application, displays the Macintosh and DOS view.
When a user on a DOS, Windows, or OS/2 workstation attempts to access a file or directory created with Macintosh's security rules, VINES maps its rights to the file or directory.
For more information on VINES-Macintosh access rights, see VINES User's Guide for Macintosh and Managing Users and StreetTalk.
Sharing Directories
To share directories between DOS, Windows, or OS/2 and Macintosh workstations, users must access the directories protected by one of the rights or combination of rights shown in Table 9-2.
Arrows indicate the direction of the mapping. For example, if a directory is created on a DOS workstation and the Group identifier is given Search-Read-Delete (SRD) access, a user in the group on a Macintosh has See Files and See Folders access. The reverse is not true: if the file is created on a Macintosh with See Files and See Folders privileges, the DOS user has only Search-Read access.
If a VINES directory has an access right or a combination of rights that is not in Table 9-2, DOS, Windows, OS/2, and Macintosh users cannot share a directory.
The Macintosh operating system does not have the equivalent for the following rights or combination of rights:
Delete Read Read-Delete Search Search-Delete
The Macintosh settings of See Files and See Folders by themselves do not have a VINES counterpart.
VINES maps access rights between different operating systems in a way that does not let users undermine the security of one file system when accessing files from another system.
Sharing Files
To share files among DOS, Windows, or OS/2 and Macintosh workstations, users must access files that are protected by one of the combinations of rights shown in Table 9-3. All the arrows point in both directions. Macintosh directory-level rights do not affect how rights on files are mapped.
VINES and Macintosh have inheritance rules that determine how subdirectories and files inherit access rights from the directory in which they were created. The differences are important when different types of workstations share files.
Macintosh Inheritance Rules
Under Macintosh inheritance rules, the user who creates a folder is its Owner. The folder becomes a private folder. If the creator of a folder is not the Owner of the parent folder, the rights on the new folder can be made different from those on the parent folder. Access privileges assigned to the parent folder always protect new files.
The creator of a folder and the group administrator can set access rights so that others can share information, but the creator still owns the folder. The administrator or the Owner can change the Owner.
VINES Inheritance Rules
Under VINES inheritance rules, new directories inherit the ARL that was assigned to the parent directory. See Figure 9-9. New files inherit access rights according to the New File ARL of the parent directory. A user cannot create a directory and change its access privileges so that they differ from those of the parent directory unless the user owns it or has Control access.
Which Rules?
When you set ARLs for Macintosh users, you have the choice of letting Macintosh users inherit access rights according to VINES or Macintosh rules. The default is to accept the Macintosh inheritance rules.
If DOS, WINDOWS, OS/2, and Macintosh users create and share files, it is recommended that you change the default so that VINES inheritance rules are in effect for DOS, WINDOWS, OS/2, and Macintosh users. VINES inheritance rules facilitate sharing files in a mixed environment. Macintosh rules provide an extra measure of security but make file sharing more difficult.
For more information, see Managing VINES Security.
Macintosh Access Rights Worksheet
You can use the Macintosh Access Rights Worksheet, shown in Figure 9-10, to configure access rights for Macintosh users. Macintosh terminology refers to the VINES World identifier as Everyone.
A copy of the worksheet is in Appendix A.
Blocking the User's View of Access Rights
VINES lets you limit the visibility of access rights to a user who runs the SETARL program. If you want to limit the views that can appear, use the DOS SET command with the environment variable VIEWS= and the arguments V (VINES) or M (Macintosh).
You can run the SET command from the DOS command line before entering the SETARL program to control a single session with SETARL, or you can place it in a user profile to restrict views during every VINES session.
For more information on blocking views, see Managing VINES Security.
Native VINES can store files created under UNIX. This feature lets third-party developers who have the Banyan Applications Toolkit log in to UNIX and create applications that will run on a native VINES server.
For information on how to make the UNIX view visible and how VINES supports UNIX naming and security features, see Managing VINES Security.
DOS and Macintosh file attributes let you manage and control access to files. VINES maintains its own set of attributes for each operating system and extends attribute support to directories.
Note: Do not confuse file and directory attributes with StreetTalk attributes. StreetTalk attributes are properties of StreetTalk objects. They let you categorize and search for resources with StreetTalk names. File and directory attribute control access to files and directories. Chapter 3 describes StreetTalk attributes.
VINES attributes are a composite of the attributes of the different file systems. They break the attributes of different file systems into component parts and construct attributes from those parts. For example, the DOS Read Only attribute corresponds to two separate attributes in the VINES composite set: Read Only and No Delete. The Macintosh Locked attribute corresponds to three VINES attributes: Read Only, No Delete, and No Rename.
You use attributes in conjunction with the access rights lists to manage directories and files and to control access to them. The VINES SETATTR program lets you manage these attributes from the DOS command line or from the program's menu-driven user interface.
The next sections describe the meanings of attributes for files under VINES, DOS, and Macintosh.
Tables 9-4, 9-5, and 9-6 describe each of the file attributes.
Attributes such as Read Only, Hidden, and System can allow broad access or prevent access to directories and files. The Archive attribute can be used as a signal to an automatic, incremental backup program that a file needs to be backed up. (The VINES Backup/Restore program does not use the Archive attribute.)
VINES Sharing Attribute
The VINES sharing attribute is important only for files that get written to by application programs designed to run on DOS 3.00 or earlier. DOS support for file sharing began with DOS version 3.10.
With DOS 3.10, application programs can provide a sharing mode when they open a file to write to it. The sharing mode controls what happens when other requests are made to open that file while it is still in use. Applications that were written to run under DOS 3.10 usually provide a sharing mode. DOS revisions prior to 3.10 did not allow applications to specify a sharing mode.
If your site runs DOS 3.10 or greater at all network workstations and your multi-user applications are all written to run under that level of DOS, you should not change the default setting on the sharing attribute. The default setting for the sharing attribute is OFF. Changing the setting can impact network security and performance.
If you are running DOS 4.0 and applications designed to run on it, see Managing VINES Security for instructions on setting the sharing attribute.
The directory attributes are a subset of the file attributes. Tables 9-7, 9-8, and 9-9 explain the meaning of these attributes, which are similar to file attributes.
You can set attributes from the DOS command line or from menus when you run the VINES SETATTR program.
From the DOS command line, you can view and change the status of attributes to ON or OFF. When you use SETATTR to view the status, you can request the status of multiple files or directories. Whether you ask for the status of attributes for one file or for ten files, the command line version of SETATTR displays only those attributes that are ON.
From the SETATTR menu, you can manage the attributes for only one file or directory at a time. However, you can specify several files on the command line and the menu interface displays each in sequence when you press F10. You can also edit two views at one time (for example, DOS and VINES or Macintosh and VINES).
If you change the Macintosh Locked attribute, the following VINES attributes change:
Read Only No Delete No Rename
When a directory or file is first created on a DOS or Macintosh workstation, all file and directory attributes except the Archive (VINES and DOS) or the Backup Needed (Macintosh) attribute are turned OFF (-).
For more information on the mapping of VINES, DOS, and Macintosh, see Managing VINES Security.
Attribute Worksheets
Use the File Attribute Worksheet and the Directory Attribute Worksheet, shown in Figures 9-11 and 9-12, to record the attribute settings if you want to change the defaults. The defaults are OFF. An X indicates that DOS or the Macintosh operating system does not have a comparable attribute. Copies of the worksheets are in Appendix A.
Providing User Access to File Volumes
You can include commands in the user profile to automate user access to network file volumes. You can also let users set their own workstation drives to file volumes, or you can restrict them to a path on a file volume after they log in. For example, you can use the /ROOT switch of the SETDRIVE command to restrict users to certain subdirectories. Inform users of how you have set up file services on the network.
All drive settings, whether done by profiles or explicitly by users, are subject to the access rights lists of the directories on those volumes.
This section describes some of the tasks that you must perform to manage VINES file systems.
You and your users should back up files frequently, especially important files or ones that change often. Users can back up their own files onto local workstation disks at any time, through standard backup utilities.
You can make system backups of file volumes, directories, or individual files. You do this at the server console for native VINES, as explained in Banyan Server Operations Guide. Appendix A has worksheets for designing a backup schedules. You can also use the Enterprise Backup and Restore (EBR) program. Use Windows NT or third-party backup utilities to back up StreetTalk for Windows NT services and data. The StreetTalk for Windows NT Release Notice describes recommended backup utilities.
You perform the following ongoing tasks to manage file services:
Edit user profiles to provide access to file services. Create directories as needed. Set the proper access rights for each directory. Install new applications on the network and set file attributes for read-only, sharing, and execution. Monitor how a file service uses disk space. Direct users to clean up their directories periodically to free up disk space. Start or stop the file service as needed. Ensure that backups occur on schedule. Chapter 12 describes backups and contains some worksheets to help you plan doing them. Move file services from one server to another to provide additional disk space or to increase performance. Restore data from backup when needed.
Managing VINES Services, Managing StreetTalk for Windows for NT Services, and Banyan Server Operations Guide tell you how to perform all the tasks involved in managing file services. The next section presents a check list for creating a new file service.
Use the check list below to help you create and start a VINES file service:
Plan the location and naming of the file service. If possible, locate the service on the same server as the group that uses the service. If your user environment is mixed, select file names that will remain the same in all environments. Add a file service to the appropriate group and server and start the file service. Divide the file volume into subdirectories. Set up subdirectories named after each application or user or both. Set access rights on files and directories as required. Copy the appropriate application programs and other information from workstations to the proper directories of the file volume. Set the attributes of any files that require them. For example, mark the programs that are for execution-only. For each user, use the SETDRIVE command to set a network drive to the appropriate file volume and to set a subdirectory as the top-level directory. Put the command in the user's profile or in the Sample Profile of the user's group. In each DOS, Windows, or OS/2 user profile, insert a CD (change directory) command that points to appropriate subdirectories on each file volume for that user. Use the PATH command to identify directories that contain executable files the user needs. Distribute information to users as needed, including names of file volumes, where to find applications, names of directories, and so on. Determine how backups will get done and track the process as it happens. Use StreetTalk Explorer, the OPERATE and MSERVICE commands and the server logs to keep track of disk space and file volume usage. On StreetTalk for Windows NT, use the appropriate Windows NT utilities to perform these task. Create new file volumes as the needs of your users change.
When you finish reading this chapter, you should be familiar with these terms:
Drive designator - A letter from A to Z that identifies a file volume or a storage medium in a DOS, OS/2, or Windows operating system.
Directory attribute - A characteristic of a VINES or DOS directory or a Macintosh folder. VINES assigns default values for attributes that a VINES administrator can change.
Extended list - An ARL list, with up to five StreetTalk entries, that designates the file or directory access rights granted to the list's members.
File attribute - A characteristic of a VINES or DOS file or a Macintosh file.
File service - Banyan software that manages a file volume on a Banyan server. This service allows a user at a workstation to access data and applications that reside on a server's disk. A VINES administrator creates and manages the service.
File sharing - The ability of users to share files across a Banyan network and among a variety of workstation types.
File system view - One of three sets of access rights rules under which users can display or edit an ARL. These sets are the Macintosh view, the VINES view, and the UNIX view.
File volume - A portion of a server's fixed disk that contains applications and data files that VINES users share. File volumes are identified by StreetTalk names and are managed by file services.
Macintosh attribute - A characteristic of a Macintosh file or folder.
Macintosh view - The set of rules that governs how access rights (privileges) and attributes are granted to files and folders created from a Macintosh workstation and stored on a Banyan network drive.
Owner identifier - An identifier in an ARL that designates the StreetTalk user name that owns a file or directory. The default Owner depends on which set of inheritance rules is in effect.
Primary List - An ARL list consisting of the Owner, Group, and World identifiers, and the access rights granted to them. These identifiers are a mandatory component of an ARL.
VINES file service - VINES software that provides the foundation for file sharing by maintaining the components of a file service and all information associated with it. This software enables DOS, Windows, OS/2, and Macintosh users on a Banyan network to share files.
VINES view - The set of rules that governs how access rights and attributes are granted to directories and files created under DOS, Windows, or OS/2 and stored on a Banyan network drive.
World identifier - An identifier in an ARL list that applies to any StreetTalk user name. The set of access rights granted by this identifier may be modified by the Owner or Group identifiers, or by the extended list. The World identifier entry is the *@*@* StreetTalk template and cannot be changed.
For more information on the topics discussed in this chapter, see the following books in the VINES documentation set:
Managing StreetTalk for Windows NT Services
Managing AppleTalk on a VINES Network
Monitoring and Optimizing Servers
VINES User's Guide for DOS and OS/2
