Re: [9fans] troll paper

[Edouard Klein]

I'll add that it takes a special brand of courage to ask "Why has
everything got to be a file" in front of a Plan 9 crowd ;)

The off-track discussions with Daniel were enlightening. I think his
perspective on "NoT" is quite valuable, and has inspired some ideas
since I got back.


ron minnich  writes:

> The  author of the paper not only helped get the conference going this year, 
> he worked hard this and last year to make sure our youtube channel worked. He 
> also has done a lot of work
> to get faculty from U. Bamberg in Germany on board. The author was a major 
> part of making IWP9 2024 go so well.
> 
> He's also done a lot to get the Unix version of the cpu command as good as it 
> is today.
> 
> I think there is a place for a slightly off the wall talk like this.
> 
> Don't like it? Don't watch it. Want talks more to your liking? Look for the 
> next CFP for IWP9, and please contribute something! I'm looking forward to it.
> 
> On Fri, Apr 12, 2024 at 3:05 AM Anthony Martin  wrote:
> 
> "Do we really have to have our own kernel? What are
> the benefits?" ...
> 
> The IWP9 paper titled "centre, left and right" looks like
> a complete troll. Was it generated by an LLM? I read the
> whole thing and it was a waste of time. Zero stars, would
> not recommend.
> 
> Institutional Academy of the Academic Institute, lol.
> 
> The vetting process needs some work, lads.
> 
> Cheers,
>   Anthony
> 
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T51f7f5a8927e1271-M59318941e57c1af41dc21c5d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] VCS on Plan9

[Edouard Klein]

I love it when I discover that something down on my todo-list has
already been done, better than I would have, by someone else :)

Very neat tool, I'll be using it soon.
Dave Eckhardt  writes:

>> One thing i did was sometimes to create a skeletron directory
>> tree and bind *before* each single directory in /sys/src/9.
>>
>> when i needed to modify a file, you copy it in your "overlay"
>> tree.
> 
> https://9p.io/wiki/plan9/divergefs/
> 
> Dave Eckhardt

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tab2715b0e6f3e0a5-Meaea072c7f6f3266050e0ba5
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Content of your /rc/bin/service or /dis/svc ?

[Edouard Klein]

sirjofri  writes:

> 06.03.2024 11:36:39 Edouard Klein :
>
...
>>
>> I'll try to compile it on Linux and will let you know :)
>
> Well, it's designed for plan 9 systems, so you're probably out of luck on 
> linux, except you try it with plan9ports.
>

That was the plan.

> While we're talking about finger, I wrote some simple android app called
> "FingerList" some time ago (on F-droid). It displays a list of fingers in a 
> list
> format, it's intended for micro social networking with status pages and 
> whatever
> people want to use it for.
>

Installed :) Thanks !

> sirjofri

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf73851503467346f-M6b41561a554e0d062d2d2a24
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Content of your /rc/bin/service or /dis/svc ?

[Edouard Klein]

a...@9srv.net writes:

> I wonder what percentage of people who reply are going to be running a finger 
> server they wrote. :-) My tcp79 comes from my implementation, here:
> http://txtpunk.com/finger/index.html
>
> I think we've got enough interoperable unicode-aware implementations we can 
> start working on the update to the RFC now.
>
> I have a service which allows some unix hosts I run to submit vac scores 
> after they perform a backup to my venti; a slightly outdated version is here:
> https://9p.io/sources/contrib/anothy/bin/rc/tcp17038
>
> tcp411 calls pqsrv, I think the same version as on the "extra" page: 
> http://9p.io/sources/extra/
>
> I usually have at least one "poor man's nat traversal" thing running with 
> aux/trampoline.
>
> I love how easy aux/listen makes sticking trivial little services up on the 
> net. I used to have one that provided a menu of MUDs to connect to. Another 
> gave the weather, as the telnet
> service at Weather Underground started to go unmaintained (of course, mine 
> used darksky, which is now also defunct).

I forgot to mention: you may be interested about:

finger pa...@graph.no

>I made a little text-based zine server (inspired by Cara Esten's
> https://github.com/caraesten/dial_a_zine, which powered the things at 
> anewsession.com); that's up, although very lightly used: 
> http://txtpunk.com/zine/
>
> Before life got away from me last year, I was trying to get a VoIP bridge 
> working so I could plug a POTS line into my modem and get telcodata working 
> again. I think 'cp tcp2323
> telcodata' should be enough to make that zine server dialable. (Sadly, I've 
> only gotten the bridge to *place* calls over my crummy DSL line.)
>
> As a young unix sysadmin back in the 1900s, aux/listen was one of the first 
> things that caught my eye about Plan 9, in comparison to inetd and the 
> direction everyone else was headed
> from there. Certainly the growth (in multiple senses) of systemd has only 
> tightened my grip on that particular tool.
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf73851503467346f-Mc5c3a50fb7cce6b9b57854d2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Content of your /rc/bin/service or /dis/svc ?

[Edouard Klein]

hiro <23h...@gmail.com> writes:

> all this makes sense. thank you.
> i might be dense, but what's the problem with inetd exactly?
>

I have two main gripes with it:
- it runs as root, in order to switch users when launching a server, and
therefore is a security risk.
- it can be configured only by root, or if you share the file with a
group, there's no fine-grained control over who can do what. In
contrast, files in a dir can be chowned to individual users, or
different groups, allowing a per-port per-user attribution scheme, which
is very handy on a multi-user system :)




> On 3/5/24, a...@9srv.net  wrote:
>> I wonder what percentage of people who reply are going to be running a
>> finger server they wrote. :-) My tcp79 comes from my implementation,
>> here: http://txtpunk.com/finger/index.html
>>
>> I think we've got enough interoperable unicode-aware implementations we can
>> start working on the update to the RFC now.
>>
>> I have a service which allows some unix hosts I run to submit vac scores
>> after they perform a backup to my venti; a slightly outdated version is
>> here: https://9p.io/sources/contrib/anothy/bin/rc/tcp17038
>>
>> tcp411 calls pqsrv, I think the same version as on the "extra"
>> page: http://9p.io/sources/extra/
>>
>> I usually have at least one "poor man's nat traversal" thing running with
>> aux/trampoline.
>>
>> I love how easy aux/listen makes sticking trivial little services up on the
>> net. I used to have one that provided a menu of MUDs to connect to. Another
>> gave the weather, as the telnet service at Weather Underground started to go
>> unmaintained (of course, mine used darksky, which is now also defunct). I
>> made a little text-based zine server (inspired by Cara
>> Esten's https://github.com/caraesten/dial_a_zine, which powered the things
>> at anewsession.com); that's up, although very lightly
>> used: http://txtpunk.com/zine/ 
>>
>> Before life got away from me last year, I was trying to get a VoIP bridge
>> working so I could plug a POTS line into my modem and get telcodata working
>> again. I think 'cp tcp2323 telcodata' should be enough to make that zine
>> server dialable. (Sadly, I've only gotten the bridge to *place* calls over
>> my crummy DSL line.)
>>
>> As a young unix sysadmin back in the 1900s, aux/listen was one of the first
>> things that caught my eye about Plan 9, in comparison to inetd and the
>> direction everyone else was headed from there. Certainly the growth (in
>> multiple senses) of systemd has only tightened my grip on that particular
>> tool.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf73851503467346f-Mfb9ec82c181d0b246e6a3dd2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Content of your /rc/bin/service or /dis/svc ?

[Edouard Klein]

a...@9srv.net writes:

> I wonder what percentage of people who reply are going to be running a finger 
> server they wrote. :-)
Indeed, it may be why I can't seem to find a good, standard
implementation: there are as many implementations as servers.

> My tcp79 comes from my implementation, here:
> http://txtpunk.com/finger/index.html
>

Your finger program is a nice illustration of /net usage. Hard to port
to Linux though ;)

Thanks for making me aware of twtxt.

>
> I think we've got enough interoperable unicode-aware implementations we can 
> start working on the update to the RFC now.
>
> I have a service which allows some unix hosts I run to submit vac scores 
> after they perform a backup to my venti; a slightly outdated version is here:
> https://9p.io/sources/contrib/anothy/bin/rc/tcp17038
>

Nice :)

Your tcp80 is also short and to the point.

>
> tcp411 calls pqsrv, I think the same version as on the "extra" page: 
> http://9p.io/sources/extra/
>
> I usually have at least one "poor man's nat traversal" thing running with 
> aux/trampoline.
>

What an aptly named program.

>
> I love how easy aux/listen makes sticking trivial little services up on the 
> net. I used to have one that provided a menu of MUDs to connect to. Another 
> gave the weather, as the telnet
> service at Weather Underground started to go unmaintained (of course, mine 
> used darksky, which is now also defunct). I made a little text-based zine 
> server (inspired by Cara Esten's
> https://github.com/caraesten/dial_a_zine, which powered the things at 
> anewsession.com); that's up, although very lightly used: 
> http://txtpunk.com/zine/
>

Well, one more thing on the to-read queue...
>
> Before life got away from me last year, I was trying to get a VoIP bridge 
> working so I could plug a POTS line into my modem and get telcodata working 
> again. I think 'cp tcp2323
> telcodata' should be enough to make that zine server dialable. (Sadly, I've 
> only gotten the bridge to *place* calls over my crummy DSL line.)
>
> As a young unix sysadmin back in the 1900s, aux/listen was one of the first 
> things that caught my eye about Plan 9, in comparison to inetd and the 
> direction everyone else was headed
> from there. Certainly the growth (in multiple senses) of systemd has only 
> tightened my grip on that particular tool.
> 9fans / 9fans / see discussions + participants + delivery options Permalink

Thank you for all these pointers :)

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf73851503467346f-Mbe2d89455c018e411194cd7d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Content of your /rc/bin/service or /dis/svc ?

[Edouard Klein]

sirjofri  writes:

> Hi,
>
> 05.03.2024 22:38:59 Edouard Klein :
>
>> Hi,
>>
>> Thank you for your answer.
>>
>>
>> sirjofri  writes:
>>
>>> Hello,
>>>
>>> I don't use /rc/bin/service anymore, but I use /cfg/machinename/service 
>>> instead. My contents are copies of what's in /rc/bin/service or my own 
>>> scripts:
>>
>> I assume that you then bind-mount /cfg/machinename/service to that
>> machine's /rc/bin/service ?
>
> Nope, because bind would only change my own namespace (or I have to bind it 
> becore aux/listen starts).
>
> In fact, it's much easier. I don't know if it's a 9front feature or if it's 
> also
> in plan 9, but if there is a /cfg/$sysname/service directory it will use that
> instead of /rc/bin/service (see the cpurc file,
> https://git.9front.org/plan9front/plan9front/36478171be59721dcc5252043fe2955cb37fc9b3/rc/bin/cpurc/f.html
> ).
>
Thanks, I had missed it because there is no /cfg in the source. Do you
happen to know how the /cfg dir is first populated during install ? Is
it all hand-written by the user ?

>
> If you think about how plan 9 should run on a network, imagine a single fs 
> with
> many cpu servers all using the same fs. All the configuration is on the fs, 
> and
> the service directories are in the /cfg/machinename/service. The cpu servers
> will run their individual configuration automatically using that mechanism. It
> just makes sense.
>

Indeed it does.

>>>
>>> tcp80 - web server
>>> tcp443 - web server but wrapped in tls
>>> ...
>>>
>>> I have some cifd running, some irc server that translates to grid chat, my 
>>> mail
>>> server (smtp and imap4), and fingerd, the files follow the usual scheme 
>>> tcpXXX.
>>> I probably missed one service or the other, but aux/listen is simple enough 
>>> to
>>> set up custom servers with arbitrary functionality.
>>>
>>
>> Would you mind sharing your fingerd and irc server ? For finger my plan
>> is to turn this one:
>> https://github.com/michael-lazar/finger2020/blob/master/finger2020 into
>> a multi-user version, but if there already is one I won't bother.
>
> Sure, here it is:
>
> https://shithub.us/sirjofri/fingerd/HEAD/info.html
>
> Note that I got some notice of potential .. path issues and I'm not sure if I
> fixed that, but just in case, you might want to fix that (and maybe send me a
> patch). Fix could be as easy as a newns or what it is in C.
>

I'll try to compile it on Linux and will let you know :)

>>> If you have exact questions about aux/listen functionality or you don't 
>>> understand something, just ask :)
>>>
>>
>> - I noticed some tcpXXX files use exec for their last line, and some
>> don't. Is there a reason ? My understanding is that exec saves one call
>> to fork per connection, and thus it would be best if it was always used.
>
> There might be some difference, maybe with log redirectors or something, but I
> don't know about that. I guess someone else can tell us more about this (and 
> the
> following topic, which is very similar)
>
>> - I noticed Inferno makes great use of servers that speak 9P on their
>>   stdstream, with its
>>   mount {some-program} /mnt/toto
>>   These programs are trivial to expose thanks to listen:
>>    listen -v 'tcp!*!toto' {some-program&}
>>   On Plan9, I ran into rc's cmd <[0=1] | echo 0 > /srv/name, then mount
>>   /srv/name /n/toto.
>>   - Is there a inferno-like shorthand for Plan 9 ?
>>   - Why the "echo 0" ? (I'm not familiar with rc).
>>
>>> Btw it's quite common to "deactivate" services by renaming the files to 
>>> have a
>>> leading "!". In general, everything that follows the naming scheme
>>>  and is executable will work.
>>>
>> why not just chmod -x them ? In a multiuser system, users may not have
>> the right to rename them.
>
> I think that _would_ work, but I think it's about readability in this case. I
> can just lc in that directory and immediately see what's relevant and what 
> not.
> With executable flag I have to run ls -l to see what's executable, and it's 
> also
> harder to parse it (sorting and filtering). A simple ! is easier to read, and
> also probably more stable in case of copying files via different filesystem
> types (like, copying the file to fat32 and back, or even having a filesystem
> without executable flags, which often results in all files bein executable).
>

Thanks for all this info !

> 
> sirjofri

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf73851503467346f-Mf9cb49da52d37653059fdaa2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Content of your /rc/bin/service or /dis/svc ?

[Edouard Klein]

Hi,

Thank you for your answer.


sirjofri  writes:

> Hello,
>
> I don't use /rc/bin/service anymore, but I use /cfg/machinename/service 
> instead. My contents are copies of what's in /rc/bin/service or my own 
> scripts:

I assume that you then bind-mount /cfg/machinename/service to that
machine's /rc/bin/service ?

>
> tcp80 - web server
> tcp443 - web server but wrapped in tls
> ...
>
> I have some cifd running, some irc server that translates to grid chat, my 
> mail
> server (smtp and imap4), and fingerd, the files follow the usual scheme 
> tcpXXX.
> I probably missed one service or the other, but aux/listen is simple enough to
> set up custom servers with arbitrary functionality.
>

Would you mind sharing your fingerd and irc server ? For finger my plan
is to turn this one:
https://github.com/michael-lazar/finger2020/blob/master/finger2020 into
a multi-user version, but if there already is one I won't bother.


> If you have exact questions about aux/listen functionality or you don't 
> understand something, just ask :)
>

- I noticed some tcpXXX files use exec for their last line, and some
don't. Is there a reason ? My understanding is that exec saves one call
to fork per connection, and thus it would be best if it was always used.

- I noticed Inferno makes great use of servers that speak 9P on their
  stdstream, with its
  mount {some-program} /mnt/toto
  These programs are trivial to expose thanks to listen:
   listen -v 'tcp!*!toto' {some-program&}
  On Plan9, I ran into rc's cmd <[0=1] | echo 0 > /srv/name, then mount
  /srv/name /n/toto.
  - Is there a inferno-like shorthand for Plan 9 ?
  - Why the "echo 0" ? (I'm not familiar with rc).

> Btw it's quite common to "deactivate" services by renaming the files to have a
> leading "!". In general, everything that follows the naming scheme
>  and is executable will work.
>
why not just chmod -x them ? In a multiuser system, users may not have
the right to rename them.

Thank you for your help :)

Cheers,

Edouard.

> 
> sirjofri

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf73851503467346f-Maa2def04fcfcb1e92523c45d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Content of your /rc/bin/service or /dis/svc ?

[Edouard Klein]

Dear 9fans,

Those of you who run a Plan 9 or Inferno box, could you please share the
contents of your /rc/bin/service or /dis/svc dir ?

I'm writing about Plan 9's listen, and I've read the scripts included in
the default distribution (e.g.
http://git.9front.org/plan9front/plan9front/c5c19dfe4998fa40de5f58f61439fd5fd65c9056/rc/bin/service/f.html),
but I'm curious to see how it's used in practice now by people who are
familiar with the system (which I'm not, since I don't run a Plan 9
box).

Thanks in advance,

Edouard.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tf73851503467346f-M66cb88b13f0e3f7dc29fae27
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Mounting a 9P filesystem under a Linux "user namespace"

[Edouard Klein]

Again for the record, if anybody is looking for a 9P2000.L FUSE
implementation, I had to write one, I used github.com/hugelgupf/p9 as a
base:

git clone g...@the-dam.org:f29p

With that, one can mount a 9P2000.L server from inside a linux 'mount
namespace'.

I'll talk about that if my paper passes the IWP9 review.

Cheers,

Edouard.


Edouard Klein  writes:

> For the record here is the lkml post
> https://lkml.org/lkml/2023/10/28/155
> Edouard Klein  writes:
>
>> Thanks Moody for the nudge in a direction I hadn't explored.
>>
>> It seems that Linux does not see 9p as been safe to mount without
>> privilege. From what I understand, only FS with the FS_USERNS_MOUNT flag
>> can be mounted in a user namespace. It seems that v9fs is not one of
>> them:
>>
>> For example, tmpfs is a safe FS, and I can do:
>> unshare --user --map-root-user --mount
>> mount -t tmpfs tmpfs mnt/mnt1/
>>
>> and it works.
>>
>> However, if I do:
>> unshare --user --map-root-user --mount
>> mount -t 9p -o trans=unix /run/9p/srv4 mnt/mnt1
>>
>> I get  mount: /home/edouard/mnt/mnt1: permission denied.
>>
>>
>> I've sent an email to the linux kernel mailing list to see if somebody
>> there has any up to date information.
>>
>> Somebody tried the same thing in 2018:
>> https://lore.kernel.org/all/39b08c53-3449-3164-c1b1-44ac587dd...@metux.net/T/
>> Seemingly without succeeding.
>>
>> The end of the above thread is a bit worrying:
>>>  plan9fs would
>>> also be a candidate for that kind of treatment if it had a maintainer.
>>
>> I did not know v9fs was unmaintained, I find that a bit surprising. It
>> does work very reliably.
>>
>> I'll keep this list updated as I make progress.
>>
>> Cheers,
>>
>> Edouard
>>
>> mo...@posixcafe.org writes:
>>
>>> Edouard,
>>>
>>> I am no Linux expert, but I think if you create a mount namespace as part of
>>> the user namespace you will be allowed to execute mounts without root. In
>>> terms of clients, I am not aware
>>> of any other then the one within the linux kernel.
>>>
>>> Regards,
>>> Moody
>>> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tb5d039f675c54046-M9d4a22b7f8e14bfa2bb23e3c
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: Charting the Future: Envisioning Plan 9 Release 5 for the 9fans Community. [Was:Re: [9fans] Supported Notebooks]

[Edouard Klein]

I, for one, will attend, barring any incident.
I will send my submission in a frenzy panic minutes before the deadline,
as one usually does.

"Don A. Bailey"  writes:

> Last I checked (you) were asking for people to sign up. What’s the actual 
> attendee count at this point?
>
>
>> On Jan 25, 2024, at 5:33 PM, o...@eigenstate.org wrote:
>>
>> Also: We're organizing IWP9 largely as a forum
>> for folks like you to figure out how to make this
>> all happen; there's going to be plenty of time
>> between talks as well as hacking days to figure
>> out what code needs to be written, what patches
>> exist in people's local trees, plenty of napkins
>> (and, if you're lucky, whiteboards) to figure out
>> designs, and even get a head start on it.
>>
>> Considering submitting some WIP or opinion papers
>> on the details of how you plan to accomplish this.
>>
>> Quoth vic.thac...@fastmail.fm:
>>> Dear 9fans, as enthusiasts and experts of Plan 9, you are undoubtedly aware
>>> of the unique position this operating system holds in the world of
>>> distributed computing. Its influence on modern computing paradigms is
>>> undeniable. In the spirit of continuing this legacy, the prospect of Plan 9
>>> Release 5 beckons, offering a pathway to not just preserve but also enhance
>>> our beloved system. This essay aims to articulate the rationale for Plan 9
>>> Release 5, focusing on the need for modernization, the potential for
>>> innovation, and the practical considerations that align with our shared
>>> passions and expertise.
>>>
>>> The Need for Modernization
>>>
>>> Technological Evolution:
>>> We've all witnessed the dramatic shifts in technology since Plan 9's last
>>> iteration. To keep Plan 9 at the forefront of utility and innovation, it's
>>> essential to adapt and update our system in line with the latest 
>>> advancements
>>> in hardware, networking, and programming languages. This evolution is 
>>> crucial
>>> to ensure that Plan 9 remains an indispensable tool in our modern tech
>>> toolkit.
>>>
>>> Security Enhancements:
>>> In our ever-connected world, the sophistication of cyber threats is a 
>>> reality
>>> we cannot ignore. It is imperative that Plan 9 evolves to include
>>> cutting-edge security protocols, safeguarding our systems and the unique 
>>> work
>>> we do from emerging cyber risks.
>>>
>>> Hardware Compatibility:
>>> The advent of new hardware architectures is an exciting challenge for us.
>>> Updating Plan 9 to support these new platforms means not only preserving its
>>> usability but also expanding our horizons to new forms of computing,
>>> something we, as 9fans, have always embraced.
>>>
>>> Fostering Innovation
>>>
>>> Research and Education:
>>> Plan 9’s novel approach to system design and distributed computing has 
>>> always
>>> been a beacon for academic research and education. A new release would
>>> re-energize our academic endeavors, offering a modern platform for continued
>>> exploration and learning, pushing the boundaries of what we can achieve with
>>> Plan 9.
>>>
>>> Community Engagement:
>>> A new version of Plan 9 stands to reinvigorate our community. This is an
>>> opportunity to deepen our engagement, attract new talent, and foster a 
>>> richer
>>> ecosystem around our shared passion. The development of Plan 9 Release 5
>>> could be a rallying point for our community, sparking new collaborations and
>>> innovations.
>>>
>>> Showcasing Plan 9’s Potential:
>>> Plan 9 Release 5 would be a powerful statement of our system's capabilities,
>>> especially in burgeoning fields like cloud computing, IoT, and distributed
>>> systems. This is our chance to demonstrate the adaptability and
>>> forward-thinking design of Plan 9 to the wider world.
>>>
>>> Practical Considerations
>>>
>>> Resource Allocation:
>>> We understand the importance of efficient resource management in bringing
>>> Plan 9 Release 5 to fruition. This means tapping into our collective
>>> knowledge, drawing on community contributions, and possibly exploring new
>>> partnerships or funding avenues.
>>>
>>> Backward Compatibility:
>>> Maintaining backward compatibility is essential to honor our past work and
>>> ensure a smooth transition. We must respect the legacy of Plan 9 while
>>> charting a course for its future.
>>>
>>> Documentation and Support:
>>> Enhanced documentation and support are crucial for the success of this new
>>> release. As a community, we can collaborate to create resources that will 
>>> aid
>>> in adoption and usability, ensuring Plan 9 Release 5 becomes a tool we can
>>> all be proud of.
>>>
>>> Conclusion
>>>
>>> The creation of Plan 9 Release 5 is more than a technological update; it’s a
>>> reaffirmation of our commitment to a system that has long been at the
>>> vanguard of computing innovation. This initiative is a step towards ensuring
>>> Plan 9's continued relevance, security, and functionality in the modern era.
>>> It's an opportunity to broaden its impact in the realms of 

Re: [9fans] Re: Mounting a 9P filesystem under a Linux "user namespace"

[Edouard Klein]

For the record here is the lkml post
https://lkml.org/lkml/2023/10/28/155
Edouard Klein  writes:

> Thanks Moody for the nudge in a direction I hadn't explored.
>
> It seems that Linux does not see 9p as been safe to mount without
> privilege. From what I understand, only FS with the FS_USERNS_MOUNT flag
> can be mounted in a user namespace. It seems that v9fs is not one of
> them:
>
> For example, tmpfs is a safe FS, and I can do:
> unshare --user --map-root-user --mount
> mount -t tmpfs tmpfs mnt/mnt1/
>
> and it works.
>
> However, if I do:
> unshare --user --map-root-user --mount
> mount -t 9p -o trans=unix /run/9p/srv4 mnt/mnt1
>
> I get  mount: /home/edouard/mnt/mnt1: permission denied.
>
>
> I've sent an email to the linux kernel mailing list to see if somebody
> there has any up to date information.
>
> Somebody tried the same thing in 2018:
> https://lore.kernel.org/all/39b08c53-3449-3164-c1b1-44ac587dd...@metux.net/T/
> Seemingly without succeeding.
>
> The end of the above thread is a bit worrying:
>>  plan9fs would
>> also be a candidate for that kind of treatment if it had a maintainer.
>
> I did not know v9fs was unmaintained, I find that a bit surprising. It
> does work very reliably.
>
> I'll keep this list updated as I make progress.
>
> Cheers,
>
> Edouard
>
> mo...@posixcafe.org writes:
>
>> Edouard,
>>
>> I am no Linux expert, but I think if you create a mount namespace as part of
>> the user namespace you will be allowed to execute mounts without root. In
>> terms of clients, I am not aware
>> of any other then the one within the linux kernel.
>>
>> Regards,
>> Moody
>> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tb5d039f675c54046-Mf8b4d705299aeeb3bc919867
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] iwp9 paper submission ?

[Edouard Klein]

Thanks Ori for the update. Please do not hesitate if you feel I can make
myself useful somehow.
o...@eigenstate.org writes:

> Quoth Edouard Klein :
>> Dear 9fans,
>>
>> I tried emailing an abstract to all iwp9*@iwp9.org addresses, but got a
>> email delivery failure notification back.
>>
>> Do anybody know where we stand on the workshop organization ? Is there
>> anything I could do to help ?
>>
>> Cheers,
>>
>> Edouard.
> 
> Short summary -- we're working on it. It's likely to be at a different
> location than we had initially announced. We're waiting to confirm
> before we put out the call for papers and specific dates.
> 
> It will be happening.
> 

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2cf2f3b242100bba-Me38f0f2f30fde4845d8501da
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Re: Mounting a 9P filesystem under a Linux "user namespace"

[Edouard Klein]

Thanks Moody for the nudge in a direction I hadn't explored.

It seems that Linux does not see 9p as been safe to mount without
privilege. From what I understand, only FS with the FS_USERNS_MOUNT flag
can be mounted in a user namespace. It seems that v9fs is not one of
them:

For example, tmpfs is a safe FS, and I can do:
unshare --user --map-root-user --mount
mount -t tmpfs tmpfs mnt/mnt1/

and it works.

However, if I do:
unshare --user --map-root-user --mount
mount -t 9p -o trans=unix /run/9p/srv4 mnt/mnt1

I get  mount: /home/edouard/mnt/mnt1: permission denied.


I've sent an email to the linux kernel mailing list to see if somebody
there has any up to date information.

Somebody tried the same thing in 2018:
https://lore.kernel.org/all/39b08c53-3449-3164-c1b1-44ac587dd...@metux.net/T/
Seemingly without succeeding.

The end of the above thread is a bit worrying:
>  plan9fs would
> also be a candidate for that kind of treatment if it had a maintainer.

I did not know v9fs was unmaintained, I find that a bit surprising. It
does work very reliably.

I'll keep this list updated as I make progress.

Cheers,

Edouard

mo...@posixcafe.org writes:

> Edouard,
>
> I am no Linux expert, but I think if you create a mount namespace as part of 
> the user namespace you will be allowed to execute mounts without root.  In 
> terms of clients, I am not aware
> of any other then the one within the linux kernel.
>
> Regards,
> Moody
> 9fans / 9fans / see discussions + participants + delivery options Permalink

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tb5d039f675c54046-M7429b33b5dade82a7a13839d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] Mounting a 9P filesystem under a Linux "user namespace"

[Edouard Klein]

Dear 9fans,

I'm trying to mount a 9p filesystem under a Linux user "namespace".

Apparently this is verboten, because mounting filesystems is dangerous.
So only fuse is permitted inside a user namespace.

I've tried
- using a setuid binary: does not work inside the user namespace,
- 9pfuse and 9pfs: don't speak 9P2000.L, the only linux 9P2000 server I
  know of is inferno's export,
- lklfuse: does not seem to be able to mount 9p, despite the code being
there.

I'm about to write my own 9P2000.L fuse wrapper, but before I dive into
that, I thought I'd ask here: has anybody ever mounted a 9P filesystem
from inside a Linux user namespace, or even better, a full blown
container ?

Thanks in advance,

Cheers,

Edouard.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tb5d039f675c54046-M2423e0177eac4b5455a8ed28
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[9fans] iwp9 paper submission ?

[Edouard Klein]

Dear 9fans,

I tried emailing an abstract to all iwp9*@iwp9.org addresses, but got a
email delivery failure notification back.

Do anybody know where we stand on the workshop organization ? Is there
anything I could do to help ?

Cheers,

Edouard.

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/T2cf2f3b242100bba-Mbd012a53497900a8e1b38f1a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription