xiaoxiang781216 commented on code in PR #8924:
URL: https://github.com/apache/nuttx/pull/8924#discussion_r1197839423


##########
binfmt/builtin.c:
##########
@@ -106,6 +106,12 @@ static int builtin_loadbinary(FAR struct binary_s *binp,
   binp->entrypt   = builtin->main;
   binp->stacksize = builtin->stacksize;
   binp->priority  = builtin->priority;
+#ifdef CONFIG_SCHED_USER_IDENTITY
+  binp->uid       = builtin->uid;
+  binp->gid       = builtin->gid;
+  binp->mode      = builtin->mode;
+#endif

Review Comment:
   > > all binp is zero by kmm_zalloc
   > 
   > Shouldn't the values come from the group structure?
   
   No, values in binp come from the binfmt provider(e.g. binfs from builtin 
table, elf come from file system).
   
   > If S_ISUID/GID is not set or not supported, then the child should inherit 
the UID/GID of the parent.
   > 
   
   Yes, UID/GID in the new task tcb is set to parent's value always when we 
create task.
   
   > I suppose this does not matter much right now since everything runs as 
root:root
   
   code in the common binfmt change to binfs/elf provided one:
   
https://github.com/apache/nuttx/pull/8924/files#diff-2712024943f67847379bc555b8cd95ac99d41ca9e009fc746ce991527ea76809R283-R293
   
   So, the sequence is:
   
   1. The new task tcb get the initial uid/gid from parent task
   2. binfs/elf set uid/gid in binp after getting info from builtin table for 
file system
   3. binfmt change tcb's uid/gid with binp's values if S_UID/S_GID is set in 
mode field



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to