[openbeos] Re: B_USER_DATA_DIRECTORY?

I hope few people here are on digest, cause this one is supersized. :]

The opinions expressed are my own, 
(and not necessarily those of the Haiku uberdevs ;) 
and so is this soapbox. Feel free to read on:

"Scott MacMaster" <scott@xxxxxxxxxxxxxxxxxx> wrote:
 ...
> BeOS only nicely supports a single local user setup.
 ...
> There needs to be a folder for each user so they can 
> each have their own desktop, BeOS menu, screen 
> saver, etc. configurations. 

Absolutely.  

Replacing 
    /boot/home/{my stuff}

 with
    /boot/home/jonas/{my stuff}
    /boot/home/strongmad/{strongmad's files}
    /boot/home/scriptkid/{all your base..}

is probably the least complicated part in 
making Haiku fully multiuser. 

(I'm guessing that retro-fitting access control on all parts on all 
currently global resources in the current API is a major undertaking. 
Like queries. That might be easy though. Only return files the current 
user is permitted access to. Other parts of the API may be trickier.)

(BTW, IMO, 'home' is starting to feel a little dated. 
I mean, we've had it since.. the 1970's?
Perhaps users, accounts, or people would be a 
better name for such a folder.)

> As far as I can tell this should be simple to do
> since BeOS already maps /boot/home/Desktop/
> as the root (and then hides /boot/home/Desktop/
> from the user, 

I'm not sure what you mean here. There's no 
mapping anything as root (/). Did you mean 
that the Desktop, being in the home folder, is
one less thing to worry about when making  
Haiku a truly multiuser system? If so, I agree.

If not: 
While I believe the Desktop and the filesystem
root are conceptually similar, serving the same
purpose in their respective UI environment, they
are not the same, or mapped in any way, from a
technical POV.

(If you open "/" in Tracker - you can do it from 
Terminal:  /boot/beos/system/Tracker /
you get the same as the special "Disks" folder:
/, except with anything not being a real-disk
filtered out, or whatever Tracker does to that effect.)

Technically ~/Desktop is a folder like any other.
The difference is presentation. While the GUI user
experience greatly benefits from the impression
of a never-failing, reliable "table top", there is no 
special treatment of this folder as far as the kernel 
is concerned.

I'm not sure if the kernel has any notion of a user's 
home folder or not. I'm thinking it's merely an effect
of the system boot script, the HOME shell variable, 
the "current directory", the set of access permissions
and the C and C++ APIs we rely on.

 ...
>didn't you make a complaint about Unix hiding stuff). 

The good/bad thing about Unix (and POSIX, I guess, which any 
respectable OS out there tries to be compatible with, if only to be 
able to use the GCC toolchain without the added pain of having to make 
it run in a non-unix env) is that they have that single unified 
filesystem. And while parts of it may be off-limits to an unpriviledged 
user account, there is still a lot of crap in there you don't want to 
burden any sane individual with. Hence, any usability-minded GUI env, 
like KDE or Gnome, will want to (if they don't already) try to hide 
parts of the filesystem hieararchy mainly by providing defaults similar 
to what Microsoft has done IIRC, (in Office?) with big buttons in the 
Open/Save to take you to your Desktop, My Documents, Network Places, 
etc. It's contrary to the Unix spirit to hide stuff from the user, 
unless it's hardware of course, :)) so I doubt that they would outright 
block major parts of the filesystem from browsing like Windows does (or 
tries to) with C:\Windows.
But who knows what they'll do to make Linux fit the desktop.

The concept of "current directory" is not not designed (AFAIK) to hide 
the system from you, but it's a good default. The equivalent of "My 
Documents". 

(Which is why it's bad to clutter ~/ with dotfiles and temp folders, 
and why Unix usually hides dotfiles from you both from the CLI and the 
GUI. If there was no clutter there would be no need to hide it. 
Additionally, Unix filemanagers, like Nautilus, store dotfiles for 
foldersettings, everywhere. Highly annoying. They don't have attributes 
like we do. Or, they have them but are reluctant to use them.)

So, do I, or do I not want to hide parts of the filesystem. Essentially 
I would like not to have a filesystem at all. I would like for some 
object-ish platform/language to replace the old file-oriented C we all 
know. But, in the meantime we're stuck with what we have. And in all 
honesty, information hiding/noise filtering or whatever one wants to 
call it, is crucial. Regardless of what your system manages, objects or 
files - you don't want to see them all at the same time.

From a BeOS POV, yes, I prefer the CLI and GUI views of the system to 
be reasonably similar without hurting either noob or nerd, and I think 
the current system works well. I don't want to hide more, and I don't 
feel a need to show more either. /dev is hidden for good reasons - it's 
only useful to C apps and shell scripts. (It's not like My Computer in 
any sense. If it was I would want it visible from the GUI.) /bin, /var 
and /tmp are similarly only of interest to shell scripts and a few 
applications, usually of Unix heritage. /bin and /etc are available 
below /boot/beos/, so it's not like they're ultrasecret either.

> Actually, the GUI won't even let you access 
> /boot/home/Desktop, while the CLI does.  

I don't think it's such a big deal, since it's 
right there in front of us all the time.

 ...
> a user might at some point create a Desktop 
> folder under home (possibly 

I don't see anything wrong in special-casing Tracker
to block any such harmful operations. I'm sure Windows
and MacOS do it all the time.

  ...
> Anyway, all that would need to be done is map 
> /boot/users/CurrentUser/home/Desktop/ 
> as the root.  For backward 
> compatibility, a symlink /boot/home/ 
> could be added that links to 
> /boot/users/CurrentUser/home/.

No links required. All your apps, including Tracker,
run as you, and start out in your home folder, 
which means ~/Desktop will always just work. 

> I do like the idea of creating a top level user 
> directory.

To move the folders to the top level, like this
   /Apps
   /Users
   /System
   ...

you'd have to rework the kernel
and the Storage Kit.  (I think)

Plus, you'd probably have to rethink how to 
present the file hierarchy in your GUI env,
which means you'd have to change 
Tracker and libtracker.so

In any case, I don't think it's a desirable change.

We  (and by that I mean people in general)
don't interact with the CLI, we interact with the
GUI, so it's much more important to present a
clean and easy to grasp GUI view of the system 
than it is to have a "user friendly" command line.

The CLI is not user friendly to begin with, so 
what's the point? While /Something is cleaner 
than /boot/Something, that "/boot/" part means 
you can present all the "Something" parts in a 
folder (with a disk icon) on the desktop.

Perhaps in the future users won't have to know about 
the internal harddisk, (thinking about the computer
as a sealed box - removable storage being disks,
the computer simply being "the box"), but in the 
meantime, it's good to be able to display partitions
in a clean and uniform way. Which BeOS does.

If you had top-level folders, that would mean your
boot disk would be mounted directly at "/", 
actually being "/". (it would have no partition name..)
All other partitions would be mounted somewhere
other than "/".. Probably as /Penguin, or something like
/Volumes/Penguin.

I much prefer the current way of 

the boot disk as:
    /boot
    /Utopia  ->   /boot   (symlink)

additional disks as:
   /Penguin
   /GratefulDead
   /BluePill

Reasonably uniform, IMO. A lot better than

/                    the boot disk
/crap.tmp      some crap file on the boot disk
/Apps/ ...
/Users/ ...
/System/ ...
/SomeFolderOnTheBootDisk
/AnotherOne
/Penguin
/Grateful
/BluePill
/thisisjustascreensaver.exe

Where files, folders of the boot disk and additional 
volumes would be mixed.

> It could contain 
> symlinks to each user directory on all mounted 
> partition and drives.  Hmm, 

Symlinks would be ok if you could duct-tape them.

Seriously though, a system seamlessly spread across multiple disks is a 
cool thing, and Unix has done it for ages, though not as seamlessly as 
I'd 
like it to be. 

I think that we should either work with what we've got, (refrain from a 
too little-too late implementation) and wait for the next paradigm in 
OS design, or, leave most of the BeOS design behind and really try to 
push the envelope. (There goes R1 and binary compatibility.)

> people could keep their user directory on a 
> usb memory stick.

Yeah, why not. This might still be possible without a  
relayout of the filesystem hierarchy.

 ...
> Seems like BeOS is doing it's own share of 
> hiding and providing two views of the file system.

I'm not complaining. Balance, good defaults and
a great user experience for both noob and nerd,
that's what I care about.

> Beyond this is security issues, which I think 
> is a large part of that GE document (it just
> doesn't address it as security issues).

Offhand I can't see anything about the filesystem hierarchy 
that would prevent a redesign to make BeOS as secure
as, Linux or BSD, but I'm no expert in security.

The BSD's usually have separate partitions (or "slices")
for parts of the hiearchy to set more strict read/write/
access policies on for example, /usr, and /home

While the BeOS default would be to install to a single 
partition, (not needing a separate swap partition, etc --
the desktop user focus from the start), it would probably
be possible to do similar things in Haiku, like it's already
somewhat possible today, even though the single-user
nature of BeOS of today makes it pointless to set more 
strict access permissions. 

>  System files and other critical files should definitely 
> be protected.  A GUI solution that involves holding shift
> if the user tries to modify a critical file isn't going to cut it.  

Agreed.

> Currently, there's nothing in BeOS that'll keep a program 
> from severely messing up the system. 

Even in a system with strict system/user separation
it's always possible for a user to completely mess
up his/her own account, but I definitely agree that we
are lacking in this department. 

Dir layout isn't that crucial to access-permissions, 
but a good layout can help, I suppose.

IMO, in the future, we won't unpack software packages.
The system will simpy "borg" them and we won't have
access to applications folders or resources unless we
ask for it. (in the role of admin, developer, or some such)


> A user should never be logged in as 
> administrator except when they need to be
> (which isn't very often).


> Outside of protecting /boot/beos, /dev, and the user
> folders, I don't see any reason the restrict user from
> creating folders and files wherever they want 

IMO, in a true multiuser system, there's little reason for a non-admin 
to 
be presented the boot disk at all. (Or any fixed, internal disk, 
depending on the people using the box - school lab, kiosk, etc - and 
the wish of the admin) The home folder, yes. Removable media, yes. But 
the boot disk is mainly a distraction to users in a managed settings, 
like on an enterprise network. A Dos/Win9x leftover. ;)

(MacOS displays disks in a similar way, but the disk is (was) actually 
used in MacOS as opposed to in Windows. Microsoft tried to clone MacOS 
and failed. I guess MacOS too is moving away from the whole it's-your-
disk-to-do-whatever-just-don't-touch-the-system-folder.)

You'd need to have the apps presented in some form though, if you're 
cut off from viewing your "C:\", so to speak.

(BTW I hate the Windows start menu / task bar.. and all the lame Linux 
lookalikes.. so it'd be nice to still be able to browse the app 
folders, but perhaps I'll get used to a non- MacOS/BeOS way of dealing 
with apps, eventually.)

> Remote logins is definitely another important 
> issue to consider.

Yeah, remote would be cool. On a private LAN behind 
one or two firewalls. :}

 ...
> BeOS really needs a good security system 
> implemented.

Something like chroot() would be a good start. :)

There are possible tools to build or shell scripts to write
which you could use to check regularly that nothing outside 
of a known and intended set of files is shared. It's no 
protection against intentional sharing of private files by 
malware or remote exploits, but at least it's something.
 
> I don't see what your issue is with partition.  
> They're conceptually the same as drives.

Eh.. What did I write? :)

Partitions are great, and I don't mind calling them disks, or
drives (occasionally), though I prefer calling them volumes. 

> You don't seem clear as to what you think should 
> happen. It seems like you think all the top level
> folders of each partition/drive should be right 
> under root. 

Nah. Definitely not. That's just what would happen if you
mounted the boot disk directly at / instead of at /boot.

> Partitions and drives show up as folders on the desktop.

And I like it. :)

> If this is implemented as I understand you, there 
> would be quite as mess of folders on the desktop
>  when partitions or drives or 
> added.  

If anyone has more than 4 partitions, they deserve a mess on their 
desktop. ;)   (more drives = more noise -- just say no!)

FWIW, there's always the Disks folder which you can turn on to hold the 
disks, if their presence or number should bother you.

> I'm not really familiar with the terms virtual root 
> and mounted root.

BeOS has a virtual root. You can't save files there. There's a rootfs 
kernel addon that manages that area.

The rootfs lets you mount volumes, as well as create
symlinks into mounted volumes, and that's all.

You -can- create folders, though, but only as 
placeholders for volumes you intend to mount.
Feel free to try:

  cd /
  mkdir ephemeral
  cd ephemeral
  touch file

When BeOS is shut down, the virtual root is not
saved anywhere. Tracker may decide to mount 
you old volumes next time you start up, but that's
another thing completely.

Btw, have a look at 'df' in Terminal:

Mount            Type     Total    Free     Flags   Device
---------------- -------- -------- -------- ------- -------------------
-------
/                rootfs          0        0 ------W
/dev             devfs           0        0 ------W
/pipe            pipefs          0        0 ------W
/boot            bfs      29310592 19129856 QAM-P-W 


In classic Linux and BSD you can do whatever at root, 
since the first mounted parition is mounted directly at /.
Whatever you create at /wonderful.nrd
is stored on that partition.

In at least one of the BSDs the kernel is stored there:

/kernel.elf  (or whatever)

And in MacOS X, IIRC.   Untidy, IMO.

Additional partitions can be mounted at
/usr, /home, /floppy, etc
off the network, another physical disk or partition. 

Having your stuff saved might seem like a good thing.
It probably is, but I prefer the virtual root for the 
reasons I've listed above. It feels cleaner.

Perhaps it's a matter of taste and preference,
or what you're used to. I think it's one of the many
details that makes BeOS a desktop OS whereas
Linux is still trying to be one. Disregarding their 
app advantage. :I

 ...
> I don't see any references to root in the GE document.
> Which suggests to me the document implies no change
> to how root is handled.

Either the author doesn't have any deeper 
understanding of how BeOS works, or, 

he thinks his design is good enough to
warrant making the necessary changes.

I'm a grumpy BeOS oldtimer, so I'm guessing on
the former, but I could be wrong. :]
 
> Well, to summarize, we need separate user 
> folders and a good security system 
> implemented.  

Agreed.

> Maybe, create a top level user folder.  

I'd rather not. :)

> Don't hide 
> /boot/home/Desktop (or anything for that matter).

Don't hide more than necessary is my temporary opinion. :)

Just keep the system clean.

/Jonas Sundström.           www.kirilla.com

Other related posts: