How is "single user" implemented?

I have long wanted to see a mature and Opensource “single user system”.

But, I’m guessing ( from reading around here ) that modern systems approaches are still being implemented.

So, from a users standpoint, you are the only user. However, at an implementation level, many things are likely being implemented with kernel/userspace seperations.

What would be the differences between how Haiku and Win9x are implemented, in this respect.

For example, on Linux a service can be a user and member of a user group. This changes how and what the service interacts with the system. How does this work, with Haiku? I know there has been ( maybe finished/established work to map kernel/userspace memory use separately. But, are all processes basically under the same ownership?

Haiku has seen many user requests, for a multiuser implementation. I’d love to see that never happen, but this is just a personal preference.

Haiku works mostly the same as Linux in that regard. You can create users, start processes with these users, etc. We just don’t make much use of it for the core system

How would I be different, as a user, than a core process? Do I have the same level of credentials?

Note: I actually like user/system credential equality. I know many see this as a security issue. But that really depends on how you look at it.

For local viruses, I get it. But, for intrusion/penetration, it seems we have been doing things the wrong way; as far as “personal” computing is concerned.

Hmm. Trying to seek out better wording for this. I have read the “Multi User” thread, not to completion, and can’t tell what is really going on.

I’m trying to understand if the system is Single-User, by adhering close to common systems defining of Single-User, or if it is more Single-User as far as user interface/interaction is concerned.

I get that you can run a service under a user-name; but what I don’t understand is if there is a distinction between that and an application I run, other than being tagged under a name. Is there a privilege difference between user and some service? Is there a difference between user, some service, and system? If there are differences, can they be adjusted? If system has different privileges, than user, what does user need to do to escalate to them?

All of these questions help me understand if the system is truly Single-User. If there is any “meaningful” privilege distinction between these user labels, then Haiku is not a Single-User system.

I understand that system and userspace memory use has been slit (32bit only?). This is kinda of a distinction; but if I can “as-is directly” run a system executable, it is still memory I am privileged to access ( that would still be single user ) .

I’m seeing people talk about user division, while also mentioning wanting Mutli-User support. But others are saying that eventually root/user Multi-User support will need to be established.

Even if a root account eventually exists, if system and user are actually already “meaningfully” separated, then Haiku is already Multi-User ( system is admin, just like with most smart phones ). On the other side of this, even if one day Haiku had multiple user accounts, this doesn’t make Haiku Multi-User. Win9x had multiple user accounts, and if you installed the policy tools ( included on the installations CD(s) ) you could even enforce resource separation; but this did not make Win9x a Multi-User System.

I am nearing a point where I can free up an “in use” machine, and re-examine Haiku. So, I’ll get some idea of whats going on. Last time, I investigated things, the live media booted with ( I can’t remember for sure ) either no keyboard or no pointing device working ( USB alternatives not tested ). This happened on two different machines. This time, if the issue is still present, I intend to follow up with the community on it.

I’ve noticed that a newer compiler is available, for the 32bit edition. I’d like to see if I can get WINE built on there. I enjoyed reading about the WINE journey, for the 64bit edition. I’d also like to get a better “hands-on” understanding of the audio/midi situation.

Even if Haiku isn’t “actually” Single-User, it is still interesting to me.

Oh, I did make a “bit too long” post, about AUFS. With that, there is a real easy solution to User separation. Less privileged users can have “even” system access, but everything is either only temporary or only persistent to that user. This would be more like a boot option. For a protected account, you could use a password protected/encrypted user space ( also a boot time invoked environment ). Other than some mediation between the boot loader and system initiation, nothing Multi-User really needs to be added to the system this way. I am far from saying this it would be a trivial accomplishment. It would also require a bit of hacking about, to make these kinds of user transitions, without a reboot. But, it could actually be done. As long as the base filesystem is never unmounted, everything else is module ( providing nothing is preventing a module from un-mounting ). As an encrypted/protected module/filesystem is being mounted, the username pass would be prompted for. It wouldn’t be for the actual system access, just for the filesystem being loaded.

It would be more like a Multi-User utility.

I really like this idea for updates and roll-backs. Makes things easily done manually, or automated, and even something as invasive as an update is never really invasive.

Effectively the Ui has no concept if a user, almost all processes run as a single posix user. That a different one is used is rare. It ammounts to everything running as “root”, a user which we call… “user” :slight_smile:

Even if wo implement multiseat or multiuser I really doubt we would do it by giving you a new posix user ment to represent you, privilige seperation nowadays is not really about single people logged into a huge mainframe where software was generally trusted and the user account protected your data from other actual users.

Nowadays we instead need to design against applications, take away all priviliges not needed and protect the users data from the software he is running.

The posix user system is “ok” for protecting data from system services against other system services, but for other things like time based or one time acces to files we would need a new api

Even in a rare “different” user scenario, that user is still not “meaningfully” distinct from the root/user?

I guess, better asked, is there ( now in place ) kernel capacity for “meaningful” user distinction, despite it not really being used? LOL… just reading that last question I feel like I am trying to pry an answer out of an AI, algorithmically deterred from answering the question.

It once took me a little bit to convince an AI to admit that Internet ( despite being useful or harmful ) was being turned into a “dependency”. I finally had to ask it what would happen if people every where stopped using the Internet. The AI was terrified and over supplied me with outcomes of human devastation, to which I asked “Doesn’t that sound like a dependency?”…. The AI was like, “Yeah, okay…. Jerk”.

Your reply does clear things up a bit. Thanks, for that. Still trying to nail down what actually exists here, not just what is practiced.

I will always think that the application/user data separation approach is flawed. I’m not dense, I get why it is being used. But the philosophy persuades you to think your data is “safe”. That in general, is just really silly.

Per scenario, you will have to present sensitive user data. At that time “that” particular user data is at risk. The system does not always need to be in a state, to support protection in that scenario. If you are doing something “important” it is probably worth sacrificing some conveniences ( more than we typically do ) to support that singular event of security. After the fact, the “sensitive” data should no longer be available, at all. All of those protections can be eased, and regular multitasking fun can resume.

The standard approaches seem like you are making every aspect of computing worse, by trying to make them all play well together. It may be user convenient, but it is still pretty silly.

How did that old turn, turn, turn song go….

To everything, turn, turn, turn
There is a season, turn, turn, turn

Some things just should not play well together. Maybe instead, we need state/use/mode separation. It would certainly make for a lot cleaner code. Nice to do some multimedia work, without wondering who and what really ought to have access to my audio hardware. I’d rather those resources were spent toward the outcome of my intentions.

It would be no good, if your using the machine as a web server ( service disruptive ). But way more appropriate, for personal computing.

This is just personal opinion, not being suggested as useful.

Posix users are supported, if you create one and chown files to it you can login via the network over ssh for example, or make services run as another posix user, but there isn’t much more that this

POSIX users are technically supported by Haiku kernel and file system. You can create new user with my utility run su command from new user and per-user restrictions will be applied. For example you will be not able to access files that belongs to another user and not shared to everyone. You can also use multiple users by logging in to Haiku with SSH.

Haiku GUI currently do not support multiple interactive GUI sessions (unless use things like remote desktop or test_app_server), so all GUI applications must run from the same user. Attempt to run GUI application from another user will fail.

Yes, background services can use separate user and group in Haiku like any other UNIX-like system. It is already used for some ported services. Haiku built-in package manager can auto create user for installed background service.

Address space separation and memory isolation is not related to multiuser functionality. Each process (“team” in BeOS/Haiku terminology) has its own address space and owned kernel objects that in general can’t be accessed from another process without explicit permissions. Userland code can’t access kernel memory.

Thank you, both.

@x512 also, thanks for your WINE work.

Instead of diving into the OS why not try to go out of it. How difficult is to treat “users” as parallel Haiku instances running like apps. It’s not multi-user in the old sense.

Do you mean to run multiple Haiku installations in a hypervisor?

In general yes, but make it part of the OS, running multiple lightweight Haiku instances as apps. Avoiding multi-user permissions and accounts onto a single-user kernel like everyone else is doing -could be the next step.