A restart of openHAB causes file permissions to change in ~openhab/.ssh

rlkoshak · January 12, 2016, 3:15pm

I’m seeing weird but consistent behavior. Whenever I restart openHAB all of the files in ~openhab/.ssh change from -rw------- to -rw-r--r--. This is a problem because when I attempt to ssh from the exec binding using those keys it won’t let me because the file permissions are too open on the private key.

So my questions are:

What is changing the file permissions?
Is there a way to prevent this from happening?

I know I can write a system started rule to change the permissions back but this behavior is so weird I’d rather know the cause.

Thanks.

watou · January 12, 2016, 3:57pm

Is this new with 1.8.0? Take a look at /usr/share/openhab/bin/setpermissions.sh to see if that is the source.
Do you have symbolic links in your file system that are being traversed to ~openhab? @theo, is this new?

rlkoshak · January 12, 2016, 4:08pm

I suspected this behavior with 1.7.1 was occurring. I was only able to confirm that it was indeed happening this morning.

You know I saw that script a while back and promptly forgot it even existed. I should have known to look there first. It is indeed the source of the changing file permissions. It appears to recursively run a chown and a chmod 755 on, among others ${OPENHAB_HOME_DIR} which would account for the changes in file permission.

I suppose I assumed that setpermissions.sh would only be run at install but if the script is indeed the source of this problem I guess that means it is run every time OH starts.

I do have a symbolic link to webapps to a folder in my user’s account so I can source control my weather webview and any new icons I add and such.

I also have a shell script that I put in /etc/openhab/configurations/scripts and I see that setpermissions.sh is also stripping the execute permissions off of that script.

I feel better about knowing where this is coming from.

I know how I can work around it for myself. Do you think this rises up as a true problem that I should file an issue for or just file it away into my bag of things to remember?

watou · January 12, 2016, 4:32pm

If the script is changing permissions on files/directories that it didn’t install, then that would seem like unwanted behavior to me. But if it’s happening because you set up symbolic links that the script is recursing into, then “you did it to yourself” if you like. In short, if this issue is likely to “get” other users who didn’t do special cusomization that brought it on, then it would warrant an issue, IMHO.

rlkoshak · January 12, 2016, 4:56pm

Well, it did install ~openhab but it didn’t install ~openhab/.ssh I created and populated that directory.

It really isn’t happening because of symbolic links. The .ssh folder is a new folder with its own files, not a link to somewhere else. But I do realize that is a quibble that doesn’t really change your point.

The only gotcha is one exceptionally common use case I see on the forum at least, and one that many struggle with mightily, is to do an Exec that includes an ssh command. If one sets up keys so you can do the ssh without providing a password (good security practice) then you have to put those keys in ~openhab/.ssh so the openhab user can log in. And if you do put your keys into .ssh the permissions on the private key at least has to be -rw------- or else the ssh command will fail.

I’m not recommending that this rises to the level of needing an issue and being fixed, but I do believe it is a common enough use case to warrant a least perhaps a wiki page example and document it as one of the many things that can trip you up if you want to ssh as the openhab user.

Next to zwave issues, Exec bindings that try to ssh seem to me to be the second most common problem people ask for help on this forum.

watou · January 12, 2016, 5:05pm

That’s actually arguable. If the openhab user didn’t exist prior to install, the install creates the user, but no files are actually installed into ~openhab – the creation of that user’s home directory is just a side effect of creating the user that’s needed to run the server. (In my case, I created a normal openhab user, then installed openHAB.) So I would argue that changing permissions in ~openhab or below isn’t a good thing to do because no files are installed there. (Am I missing something?)

rlkoshak · January 12, 2016, 5:23pm

Maybe we are arguing the same thing.

The script is changing the permissions of all files and directories under ~openhab whether you created the user yourself or it was created as part of the install. It also changes all the permissions of any files you may happen to add to that user’s folder.

On my install where I let apt-get create the openhab user it appears to put ~openhab in /var/lib/openhab so it actually has the Designer workspace, zwave, and persistence directories in it. I wonder if the setpermissions.sh script assumes this is the case for all installs and is infact missing some files it should be changing permissions on for users like you who created their own openhab user. The script does not appear to look for or change anything in /var/lib/openhab directly and I wonder if that is the real intent.

At the end of the day, for me at least, if I want to run ssh using keys instead of password from openHAB I have to put the ssh keys in ~openhab/.ssh and the permissions on those key files must be user read/write only. The setpermissions.sh script breaks this for me and I wonder if it breaks it for others without their realizing it.

watou · January 12, 2016, 5:29pm

Since it’s certain that users should be able to have paths like ~openhab/.ssh untouched, your explanation makes me even more convinced that setpermissions.sh should be changed to leave alone any non-openHAB paths. Would you open an issue, Rich? I think you’ve explained it well already.

rlkoshak · January 12, 2016, 5:31pm

Submitted as Issue #3776

theo · January 12, 2016, 10:33pm

I’ve commented on the issue.

bob_dickenson · January 13, 2016, 10:33am

2 cents from a side issue. The setpermissions script was one of the potential culprits when I found the problems with 1.8 clean Jessie apt-get install recommended startup sequence (systemctl … vs /etc/init.d/…) really messing things up. Not a causal statement but certainly correlated enough to comment.

Steamrunner · January 17, 2016, 6:18pm

This issue indeed also existed in 1.7.1. I fixed it by changing
find "${sprohdir}" -type f -exec chmod 644 {} ';' find "${sprohdir}" -type d -exec chmod 755 {} ';'
in setpermissions.sh to
find "${sprohdir}" -path *.ssh* -o -type f -print -exec chmod 644 {} ';' find "${sprohdir}" -path *.ssh* -o -type d -print -exec chmod 755 {} ';'
These modifications were overwritten when updating to 1.8.

rlkoshak · January 20, 2016, 11:20pm

Just a quick update to show how I’m working through the problem.

What I did was just add a couple of chmod calls using executeCommandLine to reset the permissions of the files in question to what they need to be before calling the script I actually want to execute. It works quite well and doesn’t require sudo since openhab owns the files.\

    var String results = executeCommandLine("chmod a+x /etc/openhab/configurations/scripts/*", 5000)
    logInfo("Network", "Resetting permissions on script:\n" + results)
    results = executeCommandLine("chmod go-r ~openhab/.ssh/*", 5000)
    logInfo("Network", "Resetting permissions on .ssh:\n" + results)
    results = executeCommandLine("/etc/openhab/configurations/scripts/resetGarageMqttReporter.sh", 5000)
    logInfo("Network", "Resetting garage mwttReporter. Results:\n" + results)

NCO · January 21, 2016, 3:41pm

Thanks for your workaround @rlkoshak.

I tried your first 2 lines

var String results = executeCommandLine("chmod u+x /usr/share/openhab/configurations/scripts/*.sh", 5000)
logInfo("Network", "Resetting permissions on script:\n" + results)

but obviously it doens’t work that way.
openhab.log:
chmod: cannot access `/usr/share/openhab/configurations/scripts/*.sh’: No such file or directory

rlkoshak · January 21, 2016, 3:44pm

You have to give it the paths to your actual scripts and files. If you didn’t install using apt-get your configurations folder is like somewhere else (/opt/openhab/configurations perhaps?)

NCO · January 21, 2016, 3:56pm

Hi @rlkoshak,

of course

I tried the exact same command in the console (with my openhab user account) and it works fine.
Just the call in execute command did not work.

I even tried another tipp from another thread:
var String results = executeCommandLine(“chmod@@u+x@@/usr/share/openhab/configurations/scripts/*.sh”, 5000)
Didn’t help either…

rlkoshak · January 21, 2016, 4:29pm

Well, the error is complaining that your path doesn’t exist. I’m not sure where to go from this error except to double check that the path is correct and being interpreted correctly. Try adding an executeCommandLine that does an ls on that folder and make sure that directory works.

/usr/share/openhab/configurations is an odd place for the configurations folder.

NCO · January 21, 2016, 7:42pm

Actually the path exists and (as far as I remember) it was generated during installation of openhab.
The path /usr/share/openhab/ is the main directory and the configurations folder there is a sym link to /etc/openhab/configurations/

Both
ls /etc/openhab/configurations/scripts/.sh
and
ls /usr/share/openhab/configurations/scripts/.sh
in the console work fine.

That’s really weird.

rlkoshak · January 21, 2016, 7:46pm

Well look at that. There is a symlink to /etc/openhab/configurations under /usr/share/openhab/configurations.

Don’t try it from the console, you need to run the ls using the same environment so add to your rule:

var results = executeCommandLine("ls -l /etc/openhab/configurations/scripts/*.sh", 5000)
logInfo("Permissions", results)

NCO · January 21, 2016, 8:12pm

Hi @Steamrunner

I tried your suggestion for my script folder:
/etc/openhab/configurations/scripts
which looks like this:
find "${sprohdir}" -path /usr/share/openhab/configurations/scripts/* -o -type f -exec chmod 644 {} ';'
and it seems to work.
At least the permissions are still ok.

However, when I start OH directly I get:

[....] Starting openHAB server: openhabfind: paths must precede expression: /usr/share/openhab/configurations/scripts/bt.sh
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression]

I tried to modify the “path” part, but did not succeed.
Any suggestion?