SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
USA

SCOUG-Programming Mailing List Archives

Return to [ 21 | June | 1998 ]


Date: Sun, 21 Jun 1998 14:08:24 PST8PDT
From: Peter Skye <pskye@peterskye.com >
Reply-To: scoug-programming@scoug.com
To: scoug-programming@scoug.com
Subject: SCOUG-Programming: FTP Server: File System

Content Type: text/plain

At the Saturday meeting we discussed the file system for the FTP Server
project.

We need to specify how to administer this file system before trying to
write any code for it. Obviously each user needs a profile of what
access is allowed, and this access should allow for both directory and
file specifications.

Rollin stated that, for security reasons, we want the actual file system
to be hidden from the user. For example, the user sees

/graphics/
/greg/
/new/
/programs/
/upload/

when the actual file system is

d:\imaging\apps\graphics\
f:\users\greg\
e:\webmast\reviewed\new\
d:\apps\programs\
e:\webmast\incoming\upload\

Rollin also asked how best to handle target directories with the same
name that are on different paths, i.e. how to give the user access to
both

g:\pgms
h:\pgms

since if we hide the true file system then the user ends up with the
undesirable

/pgms
/pgms

Also, there was a recommendation that access groups be allowed so users
could be assigned to these groups, which could then be individually
modified as necessary. For example, if GROUP1 consisted of

c:\programs\
d:\apps\

then user A might be given GROUP1 while user B might be given the
enhanced

GROUP1
+e:\utilities\

and user C might be given the restricted

GROUP1
-c:\programs\system\

(Note: I've always parsed directories as having a trailing "\", thus
"compile.tmp\" is a subdirectory and "compile.tmp" is a file. "\" by
itself is an empty string followed by "\" and is therefore the root
directory.)

In addition, you need group nesting since you might want to process on
the group level, i.e.

NEW GROUP3
+GROUP1
+GROUP2

creates a new group containing all of the two groups, and

NEW GROUP4
+GROUP1
-GROUP2

creates a new group containing all of the first group with all of the
second group removed.

Also, in the group and user profiles there should be a way to rename any
path so the user sees an assigned name rather than the true name. This
increases security and resolves the previously mentioned problem of
having the same directory name on two different paths.

An example of a user profile:

USER GREG
+GROUP2
+GROUPM
-GROUPF
-e:\utilities\
+g:\images\logos\ -> logo1/
+g:\localart\web\logos\ -> logo2/

The "->" operator can be any string and indicates that the specified
path should be displayed to the user as the new, not the true, name.

The system administrator should be allowed to put more than one path
into a specific user directory, i.e.

+d:\apps\ -> pgms/
+f:\systests\ -> pgms/
+d:\utils\ -> pgms/

with the understanding that this functions like a "path" statement, i.e.
if a filename occurs in more than one subdirectory then only the first
such occurrence is available (unless deleted by the user, which then
exposes then next occurrence).

The profile is processed in sequence, i.e. a path removed by the
"-GROUPF" entry would be reinstated by a following "+GROUPG" entry if
both GROUPF and GROUPG contained that path.

I do recommend allowing wildcards ("*" and "?") in both the directory
and file names, since they're very handy in some cases (I've used them
in directory name specifications). Thus,

+c:\* -> bigdir/
+d:\* -> bigdir/
+e:\* -> bigdir/

makes every file on c:, d: and e: available in the user's "bigdir/"
directory.

Trivial programming note: don't forget that directories may have
extensions.

I haven't addressed read vs. write access here since it isn't a part of
the naming schema.

The source code for processing the group and user profiles is somewhat
trivial, since they're just tables. The administrator needs some sort
of utility program to view the access profiles that gives a visual
indication of whether an entry is a directory ("name\") or file
("name"), so a missing "\" at the end of a path isn't accidentally
processed as a filename.

This "virtualized file system for FTP server" (VFSFS) has some
similarities to the Toronto Virtual File System (TVFS), a free IBM
employee-written-software utility. If you choose to use TVFS you'll
have a lot of the above functionality without doing any coding.

More thoughts, please, on how to administer the users' file rights.

- Peter Skye

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================


Return to [ 21 | June | 1998 ]



The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.