Expose default file create permissions through a new OsCfg.fpp config file #4613

kubiak-jpl · 2026-01-13T16:59:08Z


*Related Issue(s)*	4604
*Has Unit Tests (y/n)*	N
*Documentation Included (y/n)*	Y
*Generative AI was used in this contribution (y/n)*	N

Change Description

Creates an OsCfg.fpp configuration file with a default file creation mode constant. Os/Posix/File is updated to use this constant when creating new files. This allows the F Prime developer to control permissions on files created with Os::File, at least globally for the deployment

Rationale

This is a fix that would have been useful for a previous F Prime project, where the default 600 permissions caused operational headaches when the files were created by root, but access by a normal user

Testing/Review Recommendations

A small bit of test code was added to the reference topology to create files with this interface. All defined FILE_MODE_ bits were tested in one form or another on a Debian 13 system. The code was also compiled under Darwin and files were created with the expected permissions.

diff --git a/Ref/Top/RefTopology.cpp b/Ref/Top/RefTopology.cpp
index 6d18f751d..389f120f3 100644
--- a/Ref/Top/RefTopology.cpp
+++ b/Ref/Top/RefTopology.cpp
@@ -53,6 +53,10 @@ void configureTopology() {
 
     // Command sequencer needs to allocate memory to hold contents of command sequences
     cmdSeq.allocateBuffer(0, mallocator, 5 * 1024);
+
+    Os::File test_file;
+    test_file.open("test_file.txt", Os::FileInterface::OPEN_CREATE);
+    test_file.close();
 }

No testing was done on other operating systems. In particular, I am not sure how the VxWorks, FreeRTOS or Zephr OS layers will behave if they use the Os/Posix abstraction for File.

Future Work

I would also like to change the default creation mode from 600 to 666. That is the default used by multiple unix tools (touch, vim). End users can drop permissions by changing the config constant or by using umask with their application.

AI Usage (see policy)

No AI assistance used.

Os/Posix/File.cpp

 }

+mode_t PosixFile::map_open_create_mode(const U32 create_mode) {
+    mode_t out_mode = 0;


Os/Posix/File.cpp

            break;
    }
-    int descriptor = ::open(filepath, mode_flags, USER_FLAGS);
+    int descriptor = ::open(filepath, mode_flags, map_open_create_mode(Os::FILE_DEFAULT_CREATE_MODE));


Os/Posix/File.cpp

kubiak-jpl · 2026-01-14T16:31:17Z

Os/Posix/File.cpp

+
+    // Some posix systems (e.g. Darwin) use the older S_IREAD and S_IWRITE flags
+    // while other systems (e.g. Linux) use the newer S_IRUSR and S_IWUSR flags.
+#if defined(S_IREAD)


Necessary to support Linux and MacOS (ie. BSD mode_t constants)

thomas-bc · 2026-01-16T19:18:14Z

Note: we should clearly mark the configuration as Posix-specific

default/config/OsCfg.fpp

thomas-bc · 2026-01-16T21:39:06Z

default/config/OsCfg.fpp

+module Os {
+
+    @ File open mode permission bits
+    @ Constant values are derived from standard


The CCB recommends that we namespace this further to make it clear it is meant to apply only to Posix. Other implementations may borrow from it if they want (e.g. VxWorks seems to have the same API?) but it should be clear that this isn't a universal config.

So something like such:

module Os { module Posix { [ ....] } }

I disagree that this should be further namespaced.

The intention is that the FILE_MODE_ bits can be used across different backends. I only implemented it in the Posix backend because that's the only one I'm familiar with. However, the constants could be referenced by other backends. The Posix::File::map_open_create_mode maps these FILE_MODE_ bits to mode_t bits for Posix, but a similar function could be defined for VxWorks or zephyr to map FILE_DEFAULT_CREATE_MODE to the specific permission bits for those platforms.

What we want to avoid is for users to believe that this option will unambiguously happen anywhere, when that's not the case.
VxWorks and Zephyr happen to have the option to have some compliance with Posix w.r.t. file management, so I'd say it's not wrong to namespace Os::Posix when Posix is precisely what Zephyr/VxWorks are trying to comply with? (I might be reaching at straws haha)
I have no strong opinion, let's discuss with the team.

Note that we agree that, as much as possible, OSALs should attempt to respect this config

Note that we agree that, as much as possible, OSALs should attempt to respect this config

If that's the case then I think that namespacing it under Os::Posix would discourage other OSALs from using the interface, and make it look like this is only intended to be a Posix thing

Just a thought, but could using an HPP file instead of FPP solve some of these concerns (conditional compilation / includes or whatnot)? Also easier to just reuse the Posix constants rather than re-define them in FPP

thomas-bc · 2026-01-16T21:40:13Z

default/config/OsCfg.fpp

+    @ File open mode permission bits
+    @ Constant values are derived from standard
+    @ Unix values, but should not be assumed
+    @ to match


What should not be assumed to match? I'm not sure I follow.

kubiak-jpl added 2 commits January 13, 2026 08:42

Posix File mode argument configurable by end user

3a145fe

}

e89c4ec

github-advanced-security bot found potential problems Jan 13, 2026

View reviewed changes

thomas-bc requested changes Jan 16, 2026

View reviewed changes

Added bitfield to github spellings

0260e2e

Expose default file create permissions through a new OsCfg.fpp config file #4613

Are you sure you want to change the base?

Expose default file create permissions through a new OsCfg.fpp config file #4613

Uh oh!

Conversation

kubiak-jpl commented Jan 13, 2026

Change Description

Rationale

Testing/Review Recommendations

Future Work

AI Usage (see policy)

Uh oh!

Uh oh!

Check notice

Check notice

Uh oh!

Uh oh!

Check notice

Choose a reason for hiding this comment

Uh oh!

thomas-bc commented Jan 16, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thomas-bc Jan 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

thomas-bc Jan 16, 2026 •

edited

Loading