Shared Files Plan

Working Plan for a shared folder hierarchy on a suitable server

Server: a pc- and mac-compatible file-sharing environment, with group and individual permissions.  It needs to be sufficiently secure to prevent spills of sensitive information on the web or otherwise.  The existing sparkler server, a windows server that exports to Macs and PC's natively, has evidently met the security test since it has all of IS&T's confidential information on it now.  AFS is also a possibility if administered carefully. 

Filespace:  assuming we use a server like sparkler, we would have a directory on that server that mounts as a drive letter on Windows and a desktop folder on the Mac.  Let's call it "CSS-managers"   We'd have essentially unlimited room inside the folder to store what we will, and the ability to carve off sections of it to have more restrictive permissions as needed.

Access: the set of individuals who can attach the CSS-managers folder are on the list of people who would be invited to our Quarterly Offsites -- Director, Managers, Team Leaders, FBC, HQ Support.

Structure: We need a nested hierarchy of progressively more restricted folders, in order to preserve the security of salary data.  Team Leaders need to be able to see the salary data for their people, but not for those of any other team leader.   Managers need to be able to see all their TLs data, but may need to have data of their own that the TLs must not see.  The FBC and the Director need to be able to see all. 

The overall design is intended to provide the most public access to group documents at the outermost level of the respective group.  Documents that show more specific detail about a single manager's area would be in a subfolder dedicated to that area.  Within that manager-specific folder would be more private areas for data that should be visible only to the director, manager, and a specific team leader.  Finally there is a most private area accessible only to the director and manager.  (The FBC is able to see into all areas and is understood to hold a position of trust.)

Overall then, we'd have this scheme:

Following the layout scheme above, the precise CSS file structure for the current teams and mangers might look something like this:

Proposed Implementation

[9/19/2006]: There were suggestions about the admin structure made by Oliver and others at the 9/19/2006 offsite that have led to updates in the Admin permissions column of the table below.  They are summarized here:

• an administrator at the ./managers level can grant admin bits on otherwise-locked down folders at the levels below.  Bad.  So, the owners of the ./managers level will not have the administrative bit turned on.  The account of the director of CSS will have admin bits, so they can act to fix anything that might go wrong.
• groups of individual kerberos ids as in the original example should be replaced with an acl that contains those names.  To wit, "othomas, goguen, jfw" would be assigned a list like "css-managers-help-admin"; then when membership changes, it's just the acl that is changed in one place, and its effects ripple throughout the system without further intervention.
• similarly, we replace the principal of the director and the fbc with a list named for the role, populated by the principal of the incumbent.  To wit, css-director now holds 'jfw' but soon won't. 

* NOTE: the folder names are suggestions only; managers should have naming control within their folders within reason.  We suggest not using individual names instead of teams or roles.