Re: Great SWT Program

In article <1190953116.638586.67630@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<nebulous99@xxxxxxxxx> wrote:
On Sep 26, 6:51 am, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
First of all, the "file"system contains everything but the kitchen
sink, rather than just the actual, you know, *files*.

By "filesystem" I have in mind something along the lines described
in the Wikipedia article (http://en.wikipedia.org/wiki/File_system):
The mechanism for providing an abstract view of, and/or organizing
the bits on, a storage medium in terms of files and directories,
with associated timestamps, permissions, etc.

So a filesystem that does much more than just organize the bits on a
storage medium is surely a case of creeping *something*, right? ;)

I think of a filesystem as an abstraction built on top of whatever
the storage-medium hardware provides. Typical Unix filesystems
(without ACLs [*]) don't seem to me to be particularly bloated
with regard to features -- I mean, associated with each file are
a few timestamps, at most 12 permission bits, and two IDs (group
and owner). That doesn't seem excessive to me. The two IDs only
make sense in the context of a couple of additional files (lists
of usernames and groupnames, together with group membership),
but again, the overall setup doesn't seem so very complicated.
What am I not getting here?

[*] Access Control Lists, probably mentioned upthread.

I was under the impression that the versions of Windows that at
least make claims about being multi-user had some mechanism for
indicating which files were accessible to which users. No?

Yes, but I am fairly sure the system is more parsimonious -- just
users and read and write permission, or maybe just write permission.
Maybe allowing separate permission per user instead of just some for
the owner and some for everyone else though. I don't recall seeing any
user groups like feature at the filesystem permissions level.

Yes, that's kind of what I remember -- that one could give
different permissions for different users, in some way that's
more flexible than what the Unix model provides. (That model,
by the way, is really pretty simple. If you aren't familiar with
it I can try to summarize or find an online description.)

And to me a system that provides no multi-user capability, and
not even much of a way to make a distinction between normal-user
mode and system-administrator mode is -- well, inadequate.

Perhaps less so these days. Remember that sophisticated, multiple-user
(and especially multiple-*concurrent*-user) features developed in a
time when computing hardware was too expensive for individual
ownership and many people time-shared one system. Nowadays we have
individually-owned computers, plus servers; servers generally just
have one blanket set of permissions for remote querents, plus whatever
system for authenticating actually logged-in users. Most computers
thus need, for the logged-in users, merely to provide a superuser and
regular-user mode, to cut down on virus transmission and the like.
It's going to move in the direction of compartmentalizing things that
shouldn't affect each other not by a single person using multiple
"user" accounts at all but using various virtual machines that are not
even aware of one another (save that the OS will presumably supply the
ability to manually move data to common areas like the clipboard, and
to configure shared bits of filesystem visible to more than one VM
where necessary). It's the natural evolution of PC security.


Very likely part of my bias in favor of "proper multi-user setups"
is historical. But to me this model seems to still make sense in
my current workplace environment, which includes lab/classroom
machines intended to be used by whoever sits down in front of
them (as well as being a platform for computationally intensive
work being run in the background). I think it even makes some
sense for personal desktop machines; if all/most configuration
information is stored in a central server, desktops can have
identical, or near-identical, configurations, which should make
it easier for all of them to be managed by the local sysadmin
rather than requiring each user to be his/her own sysadmin.

<shrug>

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
.

Relevant Pages

  • Re: Great SWT Program
    ... By "filesystem" I have in mind something along the lines described ... user groups like feature at the filesystem permissions level. ... individually-owned computers, ... system for authenticating actually logged-in users. ...
    (comp.lang.java.programmer)
  • Re: Security and Sharing
    ... When they are logged in locally only the filesystem permissions are needed. ... When they access over the network they can do anything that the filesystem ... If you want then to be able to read files and browse the folder structure ...
    (microsoft.public.security)
  • Re: Security and Sharing
    ... When they are logged in locally only the filesystem permissions are needed. ... When they access over the network they can do anything that the filesystem ... If you want then to be able to read files and browse the folder structure ...
    (microsoft.public.security)
  • Re: Security and Sharing
    ... When they are logged in locally only the filesystem permissions are ... allows to them provided that the share level permissions are not less. ... "read and file scan rights". ... If you want then to be able to read files and browse the folder structure ...
    (microsoft.public.security)
  • Re: [RFC] FUSE permission modell (Was: fuse review bits)
    ... > 2) Suid and device semantics should be disabled within the mount ... I can see plenty of uses where I want a filesystem generated by ... permissions model - which will break some programs? ... For most virtual filesystems, the "remote" information does not map to ...
    (Linux-Kernel)