Strange behavior with seteuid,setegid

Not 100% sure this is the right forum.


Giving this code:


setegid(20);
  seteuid(501);


  printf("%d %d\n",geteuid(),getegid());
  printf("%d %d\n",getuid(),getgid());

  [@"toto" writeToFile:@"/Applications/toto.strings" atomically:YES encoding:NSUTF8StringEncoding error:NULL];


If I build it as a command line tool and run is with sudo, it can create the toto.strings file in /Applications.

If I add this code to a command line tool launched as a NSTask by a launchd daemon process, it can not create the toto.strings file in /Applications.


Yet, the euid,egid,uid and gid are exactly the sames in both cases.


Questions:


Is this a bug or a feature?


If it's a feature, how should it be done to be able to create the file in the second case?

Up vote post of packagesdev Down vote post of packagesdev
600 views
Posted by
packagesdev
Reply
Add a Comment

Replies

Well, that is interesting. If you run an 

fs_usage
log against this code running in a daemon you’ll see something like this: 
… lstat64   [  2]         /Applications/toto.strings                …
… fstatat64 [  2]         [-2]//Applications/.dat.nosync04d9.jNRvLA …
… open      [ 13] (RWC__E)/Applications/.dat.nosync04d9.jNRvLA      …

This is Foundation’s safe save logic kicking in. It attempts to write the file to a temporary (in this case 

.dat.nosync04d9.jNRvLA
) and then move it into position. However, this falls at the first hurdle: Something is preventing it from creating the temporary.

Looking at the parameters passed to 

open
, I don’t see anything obvious that would trigger this failure. [Edit: The following guess is completely wrong. Digging in to this some more, it’s now clear that this is a supplemental group list issue, triggered because 
/Applications
is owned by 
root:admin
.] My best guess is that some kernel MAC (Mandatory Access Control) policy is being applied to the daemon and the attempt to create a hidden file (leading dot) in a system directory (
/Applications
) is triggering it. However, I can’t be sure without digging much deeper, and I don’t have time for that in the context of DevForums.

If you want to get all the way to the bottom of this you should open a DTS tech support incident and we can pick it up there. Alternatively, I think you’ll be able to get around this by saving the file elsewhere and then doing your own atomic move of that file into this position.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware 

let myEmail = "eskimo" + "1" + "@apple.com"
Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Add a Comment