T.R | Title | User | Personal Name | Date | Lines |
---|
881.1 | What application? | SICKO::PATTERSON | Engaged to a Redhead | Wed May 30 1990 14:26 | 41 |
| > What I want to do is: Create a program in which different users
> identify themselves via password and only have access to the files
> assigned to them (throughout the whole harddisk). All other files
> should be set 'hidden' or some sort of 'no access' for that certain
> user. Like in some mailbox programs, where not everybody has access
> to all files and programs.
What sort of environment will the users be in?
Are you talking about allowing standard TOS and GEM access to every
file ( eg. they run from desktop and can do anything they want)?
This would be tough.
If you can trust your users to a reasonable degree, then
how about putting shared info in 'common' directories and
giving each user their own directory. A program would
validate the user and set all the other users directories
hidden (there is a bit in the header for hidden). This
assumes you can trust your users not to trash the common
area, and you can live with each user in a sub dir.
If you can't trust them, then you will have headaches, but
one thing you could do would be maintain separate root
directories for each user, with a shared block allocation
scheme. This would be slow at startup, but then would
allow you total freedom for your users. (well almost, a
sector edit would allow them to do very nasty things).
I'm not really up on the exact working of the ST file
scheme, but I have the books to look it up, and I sure
some of the others around here know it by heart.
This scheme is not perfect, it has some problems that
could prove to be real killers. For example, what about
maintence? You would have to log in as each user to get
to their files.
Are you talking about access from inside your application only?
Then just have a list of what files each user owns, and
don't let them at the others.
Jim Patterson
|
881.2 | Extending the TOS file system | BAGELS::FELDMAN | Jerry Feldman DTN 227-3279 | Wed May 30 1990 14:27 | 11 |
| Unfortunately, the TOS (MS-DOS) file system does not allow for any kind
of file ownership. For a general application, the task would be a
rather large task.
If you are dealing only with a limited number applications which are
written for the purpose, you could logically extend the file system to
contain ownership information.
In the case where you want this to be a general case, the file system
could logically be extended (similar to the ACL facility). In any case
it would be somewhat expensive and would be easily subverted.
|
881.3 | | GNOME::BHAMILTON | Buzz Hamilton | Wed May 30 1990 15:46 | 2 |
| If access is only via the application then you could set up a subdirectory
for each user and use only that path when accessing that user's files.
|
881.4 | subdirectories sounds good | MGOI02::FALKENSTEIN | so many girls, so little time... | Fri Jun 01 1990 06:43 | 23 |
|
re.: prev.
Well, seems that my aproach was to fantastic! I first had in mind
to use a login.prg to get the user and a program to assign the
files on HD to the different users. From the normal GEM or TOS
environment certain files should not be seen to the one who's
working with the Atari in the moment. Ok, no go!
On the other hand I'm just about to write a GEM-based Shell (some
sort of new desktop), where the subdirectory idea looks like a
good one as long as the user does not leave the shell.
I'm working on that problem, because my dad runs his own business
where two or three persons share the same Atari for different
business applications and personal data files, and one should not
hack the files of the others...
Thanx to all the replies,
Bernd
|
881.5 | I am working on it! | SUOSW4::SURAUF | | Thu Jun 07 1990 06:39 | 9 |
| Hi Bernd,
i am just working on this special thing! :-))
I will let you know when it is ready to use.
Also i will deposit it under topic 9.*
Rolf...
|
881.6 | waiting for 9.* | MGOI02::FALKENSTEIN | so many girls, so little time... | Thu Jun 07 1990 11:04 | 10 |
|
Great, Rolf!
I'm looking forward to seeing the results...
Thanks for the message.
Bernd
|