Circumnavigate fog user issues

[george1421]

@Sebastian-Roth said in Circumnavigate fog user issues:

we want to move away from that account name and make it a system account (no login allowed)

The only thing we need to check is if you disable interactive login, does that also block FTP access? I’m suspecting no, but we should at least test it to confirm. I’m not seeing a risk if we simply abandon the current fog linux account because it should have a secure password by default. If the IT admin had changed it post FOG install then its only as secure as the IT admin set the password to.

On the negative side, I’m not sure about the interactions with a Master/Storage node configuration if only one component of that configuration is updated. Will that break something? While I haven’t kept track of the status, (I’m guessing) I’m seeing (on average) one post per week where the end results was someone fiddled with the fog service account’s password or complains that they were locked out of the FOG server after installing fog.

[Sebastian Roth]

@george1421 said in Circumnavigate fog user issues:

The only thing we need to check is if you disable interactive login

Can you be more precise on this point. How do you disable interactive login? As far as I know there are half a dozen ways of doing this and none is doing it for shell/SSH and GUI at the same time.

interactions with a Master/Storage node configuration

Definitely a good point that we have to keep in mind!!!

[george1421]

@Sebastian-Roth said in Circumnavigate fog user issues:

shell/SSH and GUI at the same time

Who uses a GUI?? This isn’t MS Windows is it?

I can only speak for centos, but placing “/sbin/nologin” on the shell column of the password file should disable at least console (ssh) login. I would be surprised if the GUI ignored this parameter. I might have to spin up a centos install with a gui to test. On the other hand at what level do we go to, to protect the FOG admin from him/her self?

I think the users are most confused between the web ui admin fog and the linux service account called fog. Changing one or both may at least resolve this specific confusion.

[Sebastian Roth]

@george1421 said in Circumnavigate fog user issues:

but placing “/sbin/nologin” on the shell column of the password file should disable at least console (ssh) login. I would be surprised if the GUI ignored this parameter.

I only got as far as testing this on a OpenSuSE installtion that I had at hand and that would surely not login. But it wouldn’t print out a message to the user either. GUI login just seemed to freeze. People who don’t know how to kill the X server (crtl+alt+backspace) and use the terminals to fix things are totally lost with this and will post questions in the forums as before.

On the other hand at what level do we go to, to protect the FOG admin from him/her self?

From what I get in the forums most users running into this are very much inexperienced Ubuntu starters. Many if not all of them use the GUI to start off. Sure I would never ever advice such a thing but this is what you see in a couple of FOG beginner tutorial videos out there.

I think the users are most confused between the web ui admin fog and the linux service account called fog. Changing one or both may at least resolve this specific confusion.

I am definitely with you on this point!

[Sebastian Roth]

I just fear we make it worse not better… This is why I keep asking before making the changes to the code.

[Sebastian Roth]

Thinking a bit more about this I reckon we don’t really want to fully lock that account. It might even cause more people to ask in the forums. Better we try to inform the user as soon as we detect someone is using the account. And I mean informing beginners in particular. So for me it boils down to a couple of places we need to check and take care to inform the user.

1. Fresh install - check if account already exists and setup a new account for the user in case it does - prompting for name and password and explaining why we do this.
2. Upgrade with .fogettings (and therefore fog account) existing - check if the account was ever used to login on the machine (last | grep "^fog" and lastlog -u fog should do the job) and again setup a new account for the user - prompting for name and password and explaining why we do this.
3. Print out a message to the user when opening a shell/terminal or login as fog user (~/.bashrc seems most appropriate to me)
4. Print a X dialog when a user logs in as fog user (~/.config/autostart/ seems to be standard, works great with Ubuntu - anyone can try other distros as well?)

mkdir -p /home/fog/.config/autostart/
cat >/home/fog/.config/autostart/warnfogaccount.desktop <<EOF
[Desktop Entry]
Type=Application
Name=Warn users using the fog account
Exec=/opt/fog/warnfogaccount.sh
Comment=Warn users who use the fog system account to logon
EOF
chown fog:fog /home/fog/.config/autostart/warnfogaccount.desktop
cat >/opt/fog/warnfogaccount.sh <<EOF
#!/bin/bash
title="FOG account"
text="You seem to be using the 'fog' system account to logon and work \non your FOG server system.\n\nIt's NOT recommended to use this account! Please create a new \naccount for administrative tasks.\n\nIf you re-run the installer it would reset the 'fog' account \npassword and therefore lock you out of the system!\n\nTake care, \nyour FOGproject team"
z=$(which zenity)
x=$(which xmessage)
n=$(which notify-send)

if [[ -x $z ]]
then
    $z --error --width=480 --text="$text" --title="$title"
elif [[ -x $x ]]
then
    echo -e $text | $x -center -file -
else
    $n -u critical "$title" "$(echo $text | sed -e 's/ \\n/ /g')"
fi
EOF
chmod 755 /opt/fog/warnfogaccount.sh

[Sebastian Roth]

Ok, somehow lost track of this. Want to add this before a next release… reminder

[Sebastian Roth]

@Tom-Elliott I might find the time to add this to 1.5.x on the weekend. Just wanted to ask if you think this is a good way to go so we do things in line for 1.6.x as well and people don’t get confused.

@george1421 mentioned that from his point of view it would be a good idea to still rename the Linux account to fogsrv or something like that. Should we really? What do we do with existing installations? Leave the old account alone and create a new one or rename and lock it?

[george1421]

@Sebastian-Roth said in Circumnavigate fog user issues:

Leave the old account alone and create a new one or rename and lock it?

IMO Yes, abandon it in place. If fog set the password on that account then we know its pretty secure (or at least complex enough). If the FOG Admin changed the password on the fog linux account then there is not much we can do about security if they set the password to something like password. Either way abandoning it is the best move from my perspective.

[Tom Elliott]

@Sebastian-Roth what about staying true to fog project itself? How about username fogproject?

As most users seem to use fog for our normal stuff I think this would be descriptive enough for admins to know who and why it was created and limit the number of issues with just plain fog

[Sebastian Roth]

@Tom-Elliott Yeah, kind of like that idea. I will still add the account locking mechanisms mentioned below.

@george1421 Comments?

[george1421]

@Sebastian-Roth said in Circumnavigate fog user issues:

Comments?

I’m good with anything as long as we move off fog as the service name to avoid confusion with the web ui account as well as the bad instructions that say to install FOG as the fog linux user.

[Sebastian Roth]

@george1421 @Tom-Elliott I think I have put this off for way too long as I expected it to be complicated to handle in all cases (fresh install as well as updates). But seems like this is fairly easy to accomplish: https://github.com/FOGProject/fogproject/compare/dev-branch...rename-account

It’s still not finished yet but the basis is done and locking down the account won’t be much work I hope as I have done all the research and testing before.

Highly appreciate any comments you guys have on this. I have greped the whole code to make sure I don’t miss anywhere to change the name or handle the new name.

[Sebastian Roth]

Did some more testing and will merge this into dev-branch now before the new release. Have tested on CentOS (existing installation and fresh) as well as Debian (fresh installation). Should be good to go.