Re: [9front] user none: cwfs vs hjfs

[Stanley Lieber <sl@stanleylieber.com>]

On January 21, 2021 5:55:00 PM EST, hiro <23hiro@gmail.com> wrote:
>if multiple users need to keep state that is supposed to be separated
>and private, then those users need to authenticate in a reliable way.
>
>for this we have dp9ik, and fileservers can do user-level and even
>group-level separation, so that state can be kept by a single and not
>1 fileserver per user.
>
>On 1/21/21, hiro <23hiro@gmail.com> wrote:
>> why do you think running every service as none is a recommended practice?
>>
>> On 1/21/21, Stanley Lieber <sl@stanleylieber.com> wrote:
>>> On January 21, 2021 5:01:06 PM EST, hiro <23hiro@gmail.com> wrote:
>>>>otoh not fixing hjfs may break security assumptions.
>>>>
>>>
>>> yes. i think we should fix hjfs. a lot of stuff relies on user none doing
>>> what it does in cwfs. the most import thing is that all file systems
>>> behave
>>> the same way.
>>>
>>> that said, relegating user none to world readable files while
>>> simultaneously
>>> running basically every service as none makes isolating services, and
>>> more
>>> blatantly keeping local users out of service files, difficult if not
>>> impossible.
>>>
>>> i think they got lazy with user none. we need some finer grade control
>>> over
>>> user capabilities.
>>>
>>> sl
>>>
>>
>

do you seriously not follow what i'm saying here or are you just trying to map out a solution?

user none masks the special # file system, but (once we fix hjfs) requires world accessible files. this means any user on the file system can also access those files unless special steps are taken to prevent it. for example, upas becomes user none to process files through /mail/queue no matter who upas starts out running as. the default listener runs as none and scans the service directory. any user on the file system (including none) must be trusted with any file none can access. there's a basic conflict here that has no current solution except "run everything that requires file privacy on separate file systems."

regular users honor finer grained file permissions, but cannot be masked from the special # file system. there is a basic conflict here that has no solution at all. any regular user must be trusted with proc, binding, unbinding, this is why user none exists in the first place.

the disconnect here is between file and process permissions. they are completely different things. we have fine grained file permissions but auth is all or nothing.

sl