[Discussion] Configurable Multi-User & POSIX File Permission Support in Apache NuttX

[Abhishekmishra2808]

Add Multi-User and POSIX File Permission Support to Apache NuttX

About Me

I am Abhishek Mishra, a second-year undergraduate student studying Computer Science and Engineering at Bhagwan Parshuram Institute of Technology, Delhi, India (UTC + 05:30) currently working as SDE Intern at Winnovation.
Operating systems have always fascinated me, they’re the foundation that makes everything else in computing possible. What really caught my attention is how systems like Linux power supercomputers and handle massive workloads so efficiently. While exploring this space, I came across different types of operating systems, and that’s when I discovered NuttX. Reading about NuttX was eye-opening. It’s a completely different world compared to traditional OSes lightweight, precise, and powering things like drones and microcontrollers. That shift in perspective really pulled me in. Curious to learn more, I explored the NuttX website, found a few beginner-friendly issues, and reached out to the @acassis . Starting with small contributions, I gradually became more involved, and with the help of a very supportive community, we even made meaningful improvements to the website that led to complete transformation.
Overall, I genuinely enjoy being part of the NuttX open-source community and am excited to contribute further, especially to this problem.
All my work with the Apache community listed at the end of this proposal.

---

Why Apache NuttX and This Project

NuttX focuses on system-level design under real constraints, which makes it particularly interesting. While exploring the codebase, I observed that NuttX provides POSIX-like interfaces but lacks a complete multi-user permission model. Filesystem operations exist, but they are not tied to user identity or enforced through permission checks. This creates a gap in POSIX compliance and limits structured access control.

This project is not just about adding a feature. It is about integrating a well-established system model into an embedded environment while respecting NuttX design constraints such as build modes and resource limitations.

---

Problem Understanding

In UNIX systems, each process has credentials such as user ID and group ID, and each file stores ownership and permission bits. The kernel enforces access control by validating operations against these values. In NuttX, filesystem operations are routed through the VFS layer, but there is no consistent connection between process identity and access control. Files and device nodes do not uniformly store ownership, and permission checks are not enforced. Additionally, build modes introduce constraints. In protected and kernel builds, enforcement is possible. In flat builds, all code runs in a shared address space, allowing applications to bypass checks.

---

What Exists and What Needs to be Built

NuttX already provides a strong foundation:

• VFS layer acts as a centralized entry point for file operations
• task_group_s represents execution context
• device model is unified under /dev

However, key components are missing:

• No credential system (uid, gid)
• No ownership metadata in inodes
• No consistent permission enforcement
• No complete system call support like chmod and chown

---

Design and Approach

The design integrates a permission model into existing NuttX architecture.

Credentials (uid, gid) will be associated with task_group_s, ensuring identity is tied to execution context. Filesystem objects will be extended to store ownership and permission bits within inode structures.

Permission enforcement will be implemented in the VFS layer, where all file operations pass through a centralized path. Access decisions will compare task credentials with inode metadata using POSIX semantics, prioritizing owner, then group, and then others.

Device nodes under /dev will follow the same model to ensure consistent behavior.

In protected and kernel builds, enforcement will be strict. In flat builds, while strict enforcement is not possible, all standard VFS paths will consistently apply permission checks, and updates to permission metadata will be restricted to defined interfaces such as chmod and chown.

---

Timeline

Phase	Duration	Focus	Outcome
Community Bonding	-	Finalize design with mentors	Confirmed architecture
Phase 1	Week 1-2	Analyze VFS flow and identify enforcement points	Clear integration points
Phase 2	Week 3-4	Implement credential model	Working uid/gid system
Phase 3	Week 5-6	Extend inode metadata	Ownership and permission storage
Phase 4	Week 7-8	Implement VFS permission checks	Consistent enforcement
Phase 5	Week 9-10	Handle build modes	Correct behavior across configurations
Phase 6	Week 11-12	Testing and documentation	Stable and validated system

---

Challenges

Handling build mode differences is a key challenge. In flat builds, strict enforcement cannot be guaranteed due to shared address space, so the design must ensure correct behavior without assuming full isolation. Maintaining compatibility with existing filesystems is also important, as permission checks should not break current behavior. Additionally, the implementation must remain lightweight to suit embedded system constraints.

---

Deliverables

• Credential system integrated with task groups
• Inode metadata extended with uid, gid, and permission bits
• Permission enforcement in the VFS layer
• System calls: getuid, setuid, chmod, chown
• Tests covering permission behavior
• Documentation explaining design and limitations

---

Why I Am a Good Fit

I have spent time understanding both the theoretical and practical aspects of this problem. I studied UNIX system design and POSIX behavior, and then explored how these concepts can be adapted within NuttX.

I have contributed to Apache NuttX and other Apache projects, gaining experience working with real-world codebases and following contributor workflows.
PRs (for NuttX)

• UI Cleanup: Right-Aligned Menu, Local Fonts, Remove GitHub Stats and fix links nuttx-website#170
• Fix UI for the mobile view and Separate Content from Theme nuttx-website#168
• Redesign website layout and update UI components nuttx-website#167
• Fix typos and Contributing link nuttx-website#165
• Fix: Convert HTTP to HTTPS and fix APPS link in navigation nuttx-website#164
• Make footer year dynamic using Jekyll build time nuttx-website#163
• sched/nsh: Remove Hard-coded Default Password #18396

PRs (for Apache)

• Fix flaky OTel integration test with DNS health check (#61070) airflow#61242
• Return list of GCS URIs from FacebookAdsReportToGcsOperator airflow#61349
• Return GCS URIs from GoogleAdsToGcsOperator airflow#61334
• Generate TaskSDK datamodels airflow#61469
• UI: Show clear permission toast for 403 errors on user actions airflow#61588
• Return destination GCS URIs from ADLSToGCSOperator airflow#61463
• feat(security): centralize secure HTTP sessions and enforce TLS 1.2+ … tooling-trusted-releases#595
• Fix: Mitigate CRLF injection in email headers (Issue #603) tooling-trusted-releases#608
• Move auth buttons tooling-trusted-releases#634
• fix(alerts): show screenshot width field for PDF reports superset#37037

I have also actively engaged with maintainers during this proposal, refining the design based on feedback. This allows me to approach the project with a clear and practical perspective.

---

Availability

I will be available full-time during the GSoC period and can dedicate around 40–50 hours per week. I will stay actively engaged with the community, provide regular updates, and iterate based on feedback.

References

• Maurice J. Bach, The Design of the UNIX Operating System
• Brian W. Kernighan and Rob Pike, The UNIX Programming Environment
• IEEE Std 1003.1 (POSIX Standard), IEEE
• Apache NuttX Documentation
  https://nuttx.apache.org/docs/latest/
• Apache NuttX Source Code
  https://github.com/apache/nuttx
• NuttX VFS Implementation (fs/vfs)
  https://github.com/apache/nuttx/tree/master/fs/vfs
• Linux man-pages project (open, chmod, chown, stat)
  https://man7.org/linux/man-pages
• Linux Kernel Documentation (Filesystem and Permissions)
  https://docs.kernel.org/

Detailed Proposal PDF -> GSoC_NuttX.pdf

[acassis]

@Abhishekmishra2808 thank you for creating this issue to list the scope of the project. Seems like you used AI help to document the steps. Please avoid using it for code implementation.

@xiaoxiang781216 @raiden00pl @lupyuen please take a look and if possible add suggestions.

[raiden00pl]

I think security features should be implemented by someone with extensive security experience, and AI should definitely not be used for this. So the question is whether the author has experience implementing critical security features, or not.
The absence of some security features is better than implementing features with exploitable vulnerabilities.

[Abhishekmishra2808]

@raiden00pl While I haven’t previously implemented security-critical features at this scale, I’ve been deeply investing time in understanding NuttX internals and operating system security concepts over the past two weeks, including studying the OS materials (by @acassis ) and reviewing prior discussions and architecture details.
This GSoC proposal is not a casual attempt, it’s something I am seriously preparing for. I fully understand that security features must be implemented with extreme care and reviewed thoroughly. I would approach this incrementally, with clear design discussions and community feedback at each stage. I have used AI just for the refining the proposal grammar and content. All the brainstorming is done by me only.
My goal is to contribute responsibly and at the quality level expected by the project.

[acassis]

@Abhishekmishra2808 I think you could feed this thread like a diary blog, adding which article/book your are reading and what did you discovered. Similar what Saurav did for mnemofs: https://resyfer.github.io/blogs/mnemofs/mnemofs/

It helps other people to understand what you did and why did you take that decision.

[Abhishekmishra2808]

@acassis I have updated this to be it like thread where I shared what I have discovered until now and how it can be applied to NuttX for adding multi-user support.

[acassis]

@xiaoxiang781216 is there someone from Xiaomi that could give some advises about security for this GSoC proposal?

[xiaoxiang781216]

the check is only useful and meanful for kernel mode, the application in protected/flat mode can bypass the check easily.

[acassis]

@Abhishekmishra2808 please procedure with the official GSoC candidature: https://summerofcode.withgoogle.com/programs/2026

[Abhishekmishra2808]

@xiaoxiang781216 Thanks for pointing that out. My intention is mainly to enforce permission checks through the VFS layer in protected/kernel builds where the kernel mediates filesystem operations. In flat builds it would mainly provide a POSIX-style permission model rather than strict security guarantees.

[Abhishekmishra2808]

I’m considering ensuring that all standard VFS paths consistently apply permission checks, and restricting updates to permission metadata through defined interfaces like chmod and chown.
Since strict enforcement is not possible in flat builds, would it make sense to also introduce lightweight validation points in VFS to detect inconsistent state changes, or is maintaining correct behavior along standard code paths sufficient?