Images are created with 777 (world writable file rights) and owner root on CentOS 7

[george1421]

@aborn Why do I see FOG 1.2.0 in the file path?

AFAIK: The postinit scripts were not added until after FOG 1.2.x

[aborn]

@george1421 I updated an older Fog version to the newest because the old Fog version seemed to be unable to create or deploy windows 10 images as I was informed by our windows team

[aborn]

@Quazz Thanks again that really would be great I will ask our windows team to test that right away!
Yet another question related to your first advice

<<It might work fine if you chown -R fog:fog first, though.>>

Was this meant only for the directory /image or was that meant for all the directories and files of our Fox installation?

[Quazz]

@aborn Only for /images

Since you are reducing permissions for “everyone” (which is ok since FOG should connect with the fog user account), you need to ensure the folder structure where it places the images has the correct ownership.

chown -R fog:root /images

probably works fine too.

New images should have fog as the owner as far as I’m aware.

[aborn]

@Quazz Can’t test that any more today because the windows team left already for the weekend. We will have to create an image for a customer PC on monday though and then I will see what happens.
Wish you a nice weekend !

[aborn]

@Quazz Hi Quazz your advice was good in deed! The image we produced showed 774 but unfortunately the owner was root and the group was root too:

[root@fogserver images]# ls -al /images/dev/6c4b905470aa
total 37754292
drwxrwxr–. 2 root root 73 Oct 15 15:51 .
drwxrwxr–. 4 fog root 66 Oct 15 15:22 …
-rwxrwxr–. 1 root root 1048576 Oct 15 15:25 d1.mbr
-rwxrwxr–. 1 root root 10336542 Oct 15 15:26 d1p1.img
-rwxrwxr–. 1 root root 34582211215 Oct 15 15:51 d1p2.img
-rwxrwxr–. 1 root root 190 Oct 15 15:25 d1.partitions
[root@fogserver images]#

For this reason the fog user fails to move the image file to /images and I have to give “write rights” to others for /images otherwise the process hangs up. And of cause “w” rights for “others” are noncompliant.
Any idea where I can change a configuration so that the created files will be owned by fog instead of root? Maybe editing the same file again with a chown statement? Something like:
sed -i -e “s#chown -R root#chown -R fog#gi” /usr/share/fog/lib/funcs.sh

[george1421]

@aborn When FOS captures an image (FOS == customized linux OS that runs on target computer) the capture task runs as the root user on the target computer. That is why the files are owned by root on the FOG server. root is needed in FOS to have access to required resources to capture and deploy images.

To really fix this FOS needs to be reengineered to be a bit more secure and to use current security practices. The developers have done this while working on FOG 2.0. But really FOG 2.0 is a complete rewrite and is not ready for release.

As a patch method to get things in the state you need, we really could use a hook to call a postcapture script (akin to how the postinstall script runs). I can see several uses for this beyond your need. With a postcapture script you could then run a bash script to correct the settings on the captured files (as root) so that the linux user fog could move the files correctly. Without looking too deep into it at the moment, it sounds like an easy patch for FOG 1.5.4 and could be included in 1.5.5 as a feature enhancement. @Developers ?? I’ll look into what we need to do to patch the capture script in 1.5.4 a bit later today.

[Quazz]

@aborn The files are never chowned. I suspect this is because the initial copy uses nfs which runs as a service under the root user on the server.

You can try changing

sed -i -e "s#chmod -R 777#chmod -R 774#gi" /usr/share/fog/lib/funcs.sh

to

sed -i -e 's#chmod -R 777#chown -R fog:root "$imagePath";chmod -R 774#gi' /usr/share/fog/lib/funcs.sh

I fear this won’t work, but it’s the only quick hack that I can think of right now that might.

[aborn]

@george1421 thx george1421 ! I inserted the proposed new line now in the fog.postinit script for a try and we’ll see what happens when the next image will be created. Of cause it would be nice if your developers could solve this issue by patching 1.5.4 or adding that as a feature enhancement in 1.5.5 .

[george1421]

@aborn said in Images are created with 777 (world writable file rights) and owner root on CentOS 7:

I inserted the proposed new line now in the fog.postinit script

This is at the wrong point in time. We can use a postinit script to fix things before things happen. Current a postdeploy script will handle actions after an image is install on the target computer. What we need is a postcapture script to handle things after the image has been captured but before the image is moved from /images/dev to /images. Once the image has been captured we will use a postcapture script to reset the permissions and file ownership of the captured directory so that the FTP process can move it as fog. I can see the process in my head clearly. We just need to patch the fog.capture (guessing at name) script to make the call to a postcapture script. We should be able to mimic what is done for a postdeploy script. It shouldn’t be that hard to do, then we’ll use a postinit script to copy the patch fog.capture script to FOS before it starts doing its thing.