[9fans] directories in server registry (#s)

[9n...@9netics.com]

Would supporting subdirectories in /srv be a bad idea? It seems
because of '#s's global nature, it would be useful if an application (or its
user) could confine itself to a subdirectory. Perhaps too much kernel
overhead for the convenience it provides? I think I just talked myself
out of it.

[David Presotto]

Its been done before. I think we just need to look back in time.

I think we need to think more about permissions before going crazy
expanding /srv.

[9n...@9netics.com]

> Its been done before. I think we just need to look back in time.
>
> I think we need to think more about permissions before going crazy
> expanding /srv.

for an applications I'm working on it would be very nice to have
'#s/app/groupid/' style directories that could be bound to /srv in
that application's namespace. In this case the security model fits
because the application is confined to a minimal namespace that must
include /srv. So, if the user doesn't have the right group permission on
'#s/app/groupid/', the application wont be able to see anything.

[Fco.J.Ballesteros]

> I think we need to think more about permissions before going crazy
> expanding /srv.

I think that it'd be a good thing to let the kernel know about permission
checking in the same way that fossil does. I mean, I'd expect the same
permission rules of /... apply for stuff in #...

Perhaps a control file to write the fossil /adm/user to the kernel plus a
generic routine to check permissions would be a good way to do it.

[9n...@9netics.com]

>> I think we need to think more about permissions before going crazy
>> expanding /srv.
>
> I think that it'd be a good thing to let the kernel know about permission
> checking in the same way that fossil does. I mean, I'd expect the same
> permission rules of /... apply for stuff in #...

I just realized I missed what presotto was getting at in his reply.