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

[george1421]

Lets assume you need to set specific directory permissions for some compliance certificate.

The way FOG works, is that the files are created in /images/dev/<mac_address> as a remote root user. After the image capture is over FOS (the customized linux OS that runs on the target computer) connects back to the FOG server over the FTP protocol as the linux user fog to move the files to /images/<image_name>.

I have not tested this, but knowing from above. I would say that if you need to restrict the /images directory you should be able to set the owner of /images to fog:fog and all objects below. Then change the permissions to 600 for /images and all objects below.

The root user is root so it bypasses any directory permissions anyway. The images created will be owned by root, but I’m not sure if the permissions will be set correctly for the ftp move as fog to work right. You might have to set the permissions on /images/dev to 777 to allow the linux user fog to be able to move the files.

Ugh, this is getting a bit muddy now.

[aborn]

Thank you very much for this really quick response!
Unfortunately this is not a solution for us because 777
is against the IBM compliance policies no matter which directory or file it is (“You might have to set the permissions on /images/dev to 777”).
Of course I know how to change the rights manually to avoid findings in the
automated scan reports. But as the images are created by the Windows team
and I am working in the Linux Team I don’t always notice in time that new images
are created and transferred to my Linux Fog server.
So if there isn’t any configuration file where I can change the standard rights for new images to 774 for example - this would mean I’ll have to think about automated daily checks by a script and let ether the script
restrict the rights or do that manually after being informed via mail about new image files.

[Quazz]

@aborn I am unsure if the FTP client would be able to move the images, but you can change the chmod comment using a postinit script.

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

At any rate in /images/dev/postinitscripts/fog.postinit try adding the following:

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

The permissions are set twice, once before imaging (so files can be put there) and once after imaging (in case the files are created with different permissions for some reason).

You’ll have to test which permissions actually work yourself.

[aborn]

@Quazz Thanks for your advice!

I added the line
“sed -i -e “s#chmod -R 777#chmod -R 774#gi” /usr/share/fog/lib/funcs.sh”
to the fog.postinit script in the path /images/dev/postinitscripts/
which was obviously not configured at all until now:

[root@fogserver postinitscripts]# cat fog.postinit
#!/bin/bash

This file serves as a starting point to call your custom pre-imaging/post init loading scripts.

<SCRIPTNAME> should be changed to the script you’re planning to use.

Syntax of post init scripts are

#. ${postinitpath}<SCRIPTNAME>
sed -i -e “s#chmod -R 777#chmod -R 774#gi” /usr/share/fog/lib/funcs.sh
[root@fogserver postinitscripts]#

Then I looked for the funcs.sh script in /usr/share/fog/lib and had to find out that there is no directory fog under the path /usr/share in our fog installaion.

[root@fogserver share]# pwd
/usr/share
[root@fogserver share]# ls -al
total 228
drwxr-xr-x. 122 root root 4096 Oct 10 07:58 .
drwxr-xr-x. 14 root root 4096 Jun 5 16:36 …
drwxr-xr-x. 3 root root 19 Apr 27 16:53 abrt
drwxr-xr-x. 2 root root 4096 Apr 11 2018 aclocal
drwxr-xr-x. 3 root root 4096 Nov 30 2015 aclocal-1.13
drwxr-xr-x. 8 root root 102 Jun 5 16:38 alsa
drwxr-xr-x. 4 root root 31 Sep 30 2015 anaconda
drwxr-xr-x. 2 root root 29 Oct 10 2017 appdata
drwxr-xr-x. 2 root root 4096 Jul 2 12:25 applications
drwxr-xr-x. 3 root root 19 Apr 11 2018 augeas
drwxr-xr-x. 2 root root 4096 Oct 10 2017 authconfig
drwxr-xr-x. 7 root root 4096 Nov 30 2015 autoconf
drwxr-xr-x. 4 root root 4096 Nov 30 2015 automake-1.13
drwxr-xr-x. 2 root root 4096 Jul 18 2017 awk
drwxr-xr-x. 2 root root 4096 Apr 11 2018 backgrounds
drwxr-xr-x. 4 root root 60 Apr 11 2018 bash-completion
drwxr-xr-x. 4 root root 4096 Oct 10 2017 bison
drwxr-xr-x. 2 root root 65 Oct 5 2015 centos-logos
drwxr-xr-x. 2 root root 17 Oct 10 07:58 centos-release
drwxr-xr-x. 2 root root 4096 Oct 5 2015 cracklib
drwxr-xr-x. 2 root root 40 Oct 10 2017 cscope
drwxr-xr-x. 6 root root 4096 Jun 5 16:36 dbus-1
drwxr-xr-x. 3 root root 20 Oct 10 2017 defaults
drwxr-xr-x. 2 root root 6 Apr 11 2018 desktop-directories
drwxr-xr-x. 2 root root 36 Apr 11 2018 dict
drwxr-xr-x. 535 root root 20480 Oct 10 07:58 doc
drwxr-xr-x. 3 root root 22 Sep 20 2017 emacs
dr-xr-xr-x. 2 root root 6 Apr 11 2018 empty
drwxr-xr-x. 2 root root 18 Dec 15 2016 file
drwxr-xr-x. 3 root root 18 Sep 26 20:27 firewalld
drwxr-xr-x. 3 root root 19 Sep 30 2015 firstboot
drwxr-xr-x. 3 root root 23 Oct 5 2015 fontconfig
drwxr-xr-x. 3 root root 16 Oct 10 2017 fonts
drwxr-xr-x. 2 root root 24 Sep 18 07:40 fpm
drwxr-xr-x. 2 root root 6 Apr 11 2018 games
drwxr-xr-x. 3 root root 19 May 15 23:51 gcc-4.8.2
lrwxrwxrwx. 1 root root 9 Jun 5 16:36 gcc-4.8.5 -> gcc-4.8.2
drwxr-xr-x. 3 root root 22 Aug 5 2017 GConf
drwxr-xr-x. 3 root root 15 Aug 5 2017 gcr-3
drwxr-xr-x. 5 root root 50 May 15 23:51 gdb
drwxr-xr-x. 2 root root 90 Dec 15 2016 GeoIP
drwxr-xr-x. 7 root root 4096 Oct 10 2017 gettext
drwxr-xr-x. 3 root root 16 Oct 10 2017 gettext-0.19.8
drwxr-xr-x. 3 root root 19 Apr 11 2018 ghostscript
drwxr-xr-x. 4 root root 36 Jun 22 16:02 git-core
drwxr-xr-x. 3 root root 20 Apr 11 2018 glib-2.0
drwxr-xr-x. 2 root root 6 Apr 11 2018 gnome
drwxr-xr-x. 2 root root 44 Oct 5 2015 gnome-background-properties
drwxr-xr-x. 2 root root 4096 Jul 16 08:59 gnupg
drwxr-xr-x. 3 root root 33 Oct 5 2015 groff
drwxr-xr-x. 2 root root 79 Apr 16 16:50 grub
drwxr-xr-x. 2 root root 6 May 16 09:59 gtk-3.0
drwxr-xr-x. 5 root root 44 Jun 27 15:49 httpd
.
.
.

So I searched for the funcs.sh through all the directories and found two at different places:

[root@fogserver share]# find / -name funcs.sh
/root/git/fogproject/src/buildroot/package/fog/scripts/usr/share/fog/lib/funcs.sh
/root/fog_1.2.0/src/buildroot/package/fog/scripts/usr/share/fog/lib/funcs.sh
[root@fogserver share]#

In both funcs.sh scripts I made a grep for chmod, 777, and 774 and did not find any of those strings:

[root@fogserver share]# grep 777 /root/fog_1.2.0/src/buildroot/package/fog/scripts/usr/share/fog/lib/funcs.sh
[root@fogserver share]# grep chmod /root/fog_1.2.0/src/buildroot/package/fog/scripts/usr/share/fog/lib/funcs.sh
[root@fogserver share]# grep chmod /root/git/fogproject/src/buildroot/package/fog/scripts/usr/share/fog/lib/funcs.sh

Just to make sure made a I grep for /image too and got only the same few results and those were without any “chmod” statements:

[root@fogserver postinitscripts]# grep /image /root/git/fogproject/src/buildroot/package/fog/scripts/usr/share/fog/lib/funcs.sh

the directory to store images in (e.g. /image/dev/xyz) as the third parameter

the directory images stored in (e.g. /image/xyz) as the third parameter

the directory images stored in (e.g. /image/xyz) as the third parameter

[root@fogserver postinitscripts]#

So none of the two seems to be the script you were writing about.
The reason might be that we are runnining a different version of fog here (FOG Version 1.5.4) and therefore the installation and some pathes differ.

If I got you right the “sed” command you proposed should have looked for the string “chmod -R 777” in the script /usr/share/fog/lib/funcs.sh and change that to “chmod -R 774”
So what am I supposed to do now? The fog.postinit script will not do any good as it is now. That much is sure. I appreciate your support and thank you very much for taking your time and trying to be helpful.

[Quazz]

@aborn Postinit runs just after the kernel and init files load in on the client. (not on the server)

It will work on the unpacked filesystem in memory on the client device before the capturing of the image takes place.

It will work just fine.

[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.