start service

[dborg92]

running to issues with permissions and file ownership here.

Initially, before i started working on this, the playbook was set up to start the webauth service using the webauth user. I have absolutely no idea how this code(a2446fc) was able to run, as permissions on these files should have prevented it in my understanding. The code is copied from git and compiled as the deploy user, but started as the webauth user when the unit file starts up the service.

I'm failing to see how webauth had proper permissions to start this binary.

In short, this is why the start service role still doesn't correctly start projectmain. file permissions.

[dborg92]

I assume we definitely can not run this program as root?

[nskinkel]

That is a correct assumption. Running any of this stuff as root basically makes the entire concept of unprivileged plugins pointless. Please don't do that.

I'm not really sure what the problem is here? Just tell systemd that a service should run as a particular user, and make sure the binary has the correct permissions.

[nskinkel]

The "most correct" solution for this is to do something like:

1. Create a group like "plugins"
2. Create a separate user for every plugin we're running
3. Add users from (2) to group from (1)
4. Give the plugin executables permission to be executed by group from (1)

We should do this if you have time. If not, you can just make the plugins world executable. But separating it by group is much better.

[dborg92]

The service won't start for me unless i change the user parameter to root right now.

contents of unit file

[Unit] Description="projectmain honeypot"

[Service] Type=simple User=deploy ExecStart=/home/deploy/src/github.com/Senior-Design-May1601/projectmain/projectmain -config /etc/projectmain/main-config.toml Restart=always

[Install] WantedBy=multi-user.target

permissions for binaries:

vagrant@localhost:~$ ls -l /home/deploy/src/github.com/Senior-Design-May1601/projectmain/ total 8184 -rwxr-xr-x 1 deploy deploy 206 Apr 21 15:51 config.toml drwxr-xr-x 2 deploy deploy 4096 Apr 21 15:51 control -rwxr-xr-x 1 deploy deploy 5424 Apr 21 17:22 core.log -rwxr-xr-x 1 deploy deploy 1493 Apr 21 15:51 LICENSE drwxr-xr-x 2 deploy deploy 4096 Apr 21 15:51 logger drwxr-xr-x 2 deploy deploy 4096 Apr 21 15:51 loggerplugin -rwxr-xr-x 1 deploy deploy 2552 Apr 21 15:51 log_manager.go -rwxr-xr-x 1 deploy deploy 2899 Apr 21 15:51 main.go -rwxr-xr-x 1 deploy deploy 354 Apr 21 15:51 plugin.go -rwxr-xr-x 1 deploy deploy 1760 Apr 21 15:51 process.go -rwxr-xr-x 1 deploy deploy 8318968 Apr 21 15:52 projectmain -rwxr-xr-x 1 deploy deploy 217 Apr 21 15:51 README.md

permissions on config files.

vagrant@localhost:~$ ls -l /etc/projectmain/ total 20 -rwxr-xr-x 1 deploy deploy 30 Apr 21 15:54 dnp3-config.toml -rwxr-xr-x 1 deploy deploy 106 Apr 21 15:54 fssh-config.toml -rwxr-xr-x 1 deploy deploy 880 Apr 21 15:54 main-config.toml -rwxr-xr-x 1 deploy deploy 210 Apr 21 15:54 Splunk-config.toml -rwxr-xr-x 1 deploy deploy 315 Apr 21 15:54 webauth-config.toml

[nskinkel]

The service won't start for me unless i change the user parameter to root right now.

Please stop doing that. Just say "The service won't start". Running it as root is never a solution and it's better off being broken.

See my comment above about proper users and groups and executable permissions.

Also, remember that when creating users you need to make an unprivileged user that can't login and has no home directory, something like this:

useradd -s /usr/sbin/nologin -r -M webauth-plugin

I wrote a role that did this last fall you should be using.

These services are not designed to be run by the deploy user, so the systemd file is not correct.

[nskinkel]

This stuff was all setup correctly last fall, so if anything is broken breaking changes have been introduced between now and then.

[nskinkel]

This should be handled under #42

[nskinkel]

What actually happens when you try to start the service?

[dborg92]

the service fails to start. Based on the fact that it works as root but not as any other user leads me to think it's still a permissions issue. I'd post the systemctl show projectmain.service output but i'm in the middle of re-working code atm. i'll be sure to post that as soon as i've got the chance to reproduce it but there's not much info there.

I should include that i was able to start the binary directly as deploy user, so i don't think this is an issue of iptables/firewall permissions. We fixed that.

[dborg92]

vagrant@localhost:~$ systemctl status projectmain.service projectmain.service - "projectmain honeypot" Loaded: loaded (/etc/systemd/system/projectmain.service; enabled) Active: failed (Result: exit-code) since Thu, 21 Apr 2016 19:40:23 -0700; 233ms ago Process: 22638 ExecStart=/home/deploy/bin/projectmain -config /etc/projectmain/main-config.toml (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/projectmain.service

vagrant@localhost:~$ sudo systemctl show projectmain.service Id=projectmain.service Names=projectmain.service Requires=systemd-journald.socket basic.target WantedBy=multi-user.target Conflicts=shutdown.target Before=shutdown.target multi-user.target After=systemd-journald.socket basic.target Description="projectmain honeypot" LoadState=loaded ActiveState=failed SubState=failed FragmentPath=/etc/systemd/system/projectmain.service UnitFileState=enabled InactiveExitTimestamp=Thu, 21 Apr 2016 19:40:23 -0700 InactiveExitTimestampMonotonic=14976839222 ActiveEnterTimestamp=Thu, 21 Apr 2016 19:40:23 -0700 ActiveEnterTimestampMonotonic=14976839222 ActiveExitTimestamp=Thu, 21 Apr 2016 19:40:23 -0700 ActiveExitTimestampMonotonic=14976933479 InactiveEnterTimestamp=Thu, 21 Apr 2016 19:40:23 -0700 InactiveEnterTimestampMonotonic=14977039979 CanStart=yes CanStop=yes CanReload=no CanIsolate=no StopWhenUnneeded=no RefuseManualStart=no RefuseManualStop=no AllowIsolate=no DefaultDependencies=yes OnFailureIsolate=no IgnoreOnIsolate=no IgnoreOnSnapshot=no DefaultControlGroup=name=systemd:/system/projectmain.service ControlGroup=cpu:/system/projectmain.service name=systemd:/system/projectmain.se NeedDaemonReload=no JobTimeoutUSec=0 ConditionTimestamp=Thu, 21 Apr 2016 19:40:23 -0700 ConditionTimestampMonotonic=14977041446 ConditionResult=yes Type=simple Restart=always NotifyAccess=none RestartUSec=100ms TimeoutUSec=1min 30s WatchdogUSec=0 WatchdogTimestampMonotonic=0 StartLimitInterval=10000000 StartLimitBurst=5 StartLimitAction=none ExecStart={ path=/home/deploy/bin/projectmain ; argv[]=/home/deploy/bin/projectm PermissionsStartOnly=no RootDirectoryStartOnly=no RemainAfterExit=no GuessMainPID=yes MainPID=0 ControlPID=0 SysVStartPriority=-1 FsckPassNo=0 Result=exit-code UMask=0022 LimitCPU=18446744073709551615 LimitFSIZE=18446744073709551615 LimitDATA=18446744073709551615 LimitSTACK=18446744073709551615 LimitCORE=18446744073709551615 LimitRSS=18446744073709551615 LimitNOFILE=4096 LimitAS=18446744073709551615 LimitNPROC=3935 LimitMEMLOCK=65536 LimitLOCKS=18446744073709551615 LimitSIGPENDING=3935 LimitMSGQUEUE=819200 LimitNICE=0 LimitRTPRIO=0 LimitRTTIME=18446744073709551615 OOMScoreAdjust=0 Nice=0 IOScheduling=0 CPUSchedulingPolicy=0 CPUSchedulingPriority=0 TimerSlackNSec=50000 CPUSchedulingResetOnFork=no NonBlocking=no StandardInput=null StandardOutput=journal StandardError=inherit TTYReset=no TTYVHangup=no TTYVTDisallocate=no SyslogPriority=30 SyslogLevelPrefix=yes SecureBits=0 CapabilityBoundingSet=18446744073709551615 User=plugin_manager MountFlags=1048576 PrivateTmp=no PrivateNetwork=no SameProcessGroup=no KillMode=control-group KillSignal=15 ControlGroupModify=no ControlGroupPersistent=no IgnoreSIGPIPE=yes ExecMainStartTimestamp=Thu, 21 Apr 2016 19:40:23 -0700 ExecMainStartTimestampMonotonic=14976838940 ExecMainExitTimestamp=Thu, 21 Apr 2016 19:40:23 -0700 ExecMainExitTimestampMonotonic=14976838940 ExecMainPID=22638 ExecMainCode=1 ExecMainStatus=1