{"id":3329,"date":"2018-08-13T08:59:28","date_gmt":"2018-08-13T13:59:28","guid":{"rendered":"http:\/\/lisa.rushworth.us\/?p=3329"},"modified":"2018-08-14T15:30:53","modified_gmt":"2018-08-14T20:30:53","slug":"running-openhab2-as-non-root-user-with-usb","status":"publish","type":"post","link":"https:\/\/www.rushworth.us\/lisa\/?p=3329","title":{"rendered":"Running OpenHAB2 As Non-Root User — With USB"},"content":{"rendered":"

I’ll prefix this saga with the fact my<\/em> sad story is implementation specific (i.e. relevant to those using Fedora, RHEL, or CentOS). I know Ubuntu has its own history with handling locks, and I’m sure other distros do as well. But<\/em> I don’t know the history there, nor do I know how they currently manage locking.<\/p>\n

We switched our openHAB installation to use a systemd unit file to run as a service and changed the execution to a non-root user. Since we knew the openhab service account needed to be a member of dialout and tty, and we’d set the account up properly, we expected everything would work beautifully.<\/p>\n

Aaaand … neither ZWave for ZigBee came online. Not because it couldn’t access the USB devices, but because the non-root user could not lock<\/em> the USB devices. From journalctl, we see LOTS of error messages that are not reflected in openHAB:<\/p>\n

-- Logs begin at Sun 2017-04-30 14:28:12 EDT, end at Sun 2018-08-12 19:10:32 EDT. --\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock fi>\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: RXTX fhs_lock() Error: opening lock file: \/var\/lock\/LCK..ttyUSB-55: Permission denied. FAILED TO OPEN: No such file or directory\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: [34B blob data]\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock fi>\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: RXTX fhs_lock() Error: opening lock file: \/var\/lock\/LCK..ttyUSB-5: Permission denied. FAILED TO OPEN: No such file or directory\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: [34B blob data]\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock fi>\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: RXTX fhs_lock() Error: opening lock file: \/var\/lock\/LCK..ttyUSB1: Permission denied. FAILED TO OPEN: No such file or directory\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: [34B blob data]\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock fi>\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: RXTX fhs_lock() Error: opening lock file: \/var\/lock\/LCK..ttyUSB0: Permission denied. FAILED TO OPEN: No such file or directory\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: [34B blob data]\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock fi>\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: RXTX fhs_lock() Error: opening lock file: \/var\/lock\/LCK..ttyS31: Permission denied. FAILED TO OPEN: No such file or directory\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: [34B blob data]\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock fi>\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: RXTX fhs_lock() Error: opening lock file: \/var\/lock\/LCK..ttyS30: Permission denied. FAILED TO OPEN: No such file or directory\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: testRead() Lock file failed\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock fi>\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: RXTX fhs_lock() Error: opening lock file: \/var\/lock\/LCK..ttyS29: Permission denied. FAILED TO OPEN: No such file or directory\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: testRead() Lock file failed\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock fi>\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: RXTX fhs_lock() Error: opening lock file: \/var\/lock\/LCK..ttyS28: Permission denied. FAILED TO OPEN: No such file or directory\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: testRead() Lock file failed\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock fi>\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: RXTX fhs_lock() Error: opening lock file: \/var\/lock\/LCK..ttyS27: Permission denied. FAILED TO OPEN: No such file or directory\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: testRead() Lock file failed\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock fi>\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: RXTX fhs_lock() Error: opening lock file: \/var\/lock\/LCK..ttyS26: Permission denied. FAILED TO OPEN: No such file or directory\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: testRead() Lock file failed\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock fi>\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: RXTX fhs_lock() Error: opening lock file: \/var\/lock\/LCK..ttyS25: Permission denied. FAILED TO OPEN: No such file or directory\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: testRead() Lock file failed\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: check_group_uucp(): error testing lock file creation Error details:Permission deniedcheck_lock_status: No permission to create lock fi>\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: RXTX fhs_lock() Error: opening lock file: \/var\/lock\/LCK..ttyS24: Permission denied. FAILED TO OPEN: No such file or directory\r\nAug 12 18:36:19 server.domain.ccTLD start.sh[7448]: testRead() Lock file failed<\/pre>\n
And now my old-school Linux\/Unix knowledge totally screws me over — I expected <\/em>a uucp group with write access to \/run\/lock. Except … there’s no such group. Evidently in RHEL 7.2, they started using a group named lock with permission to \/var\/lock to differentiate between serial devices (owned by uucp) and lock files. Nice bit of history, that, but Fedora and RedHat don’t do that anymore either<\/em>.<\/p>\n
Having a group with write permission was deemed a latent privilege escalation vulnerability<\/a>, and they played around with having a lockdev binary writing files to \/run\/lock\/lockdev, the creation and configuration of lockdev was moved into systemd<\/a>, and then removed from systemd in favor of approaches<\/a> [flock(), for instance].<\/p>\n
RXTX has a hard-coded path<\/a> based on OS version — that is what is used to create the lock file. And as the \/run\/lock folder is writable only by the owner, root … that is what is failing.<\/p>\n
#if defined(__linux__)\r\n\/*\r\n\tThis is a small hack to get mark and space parity working on older systems\r\n\thttps:\/\/bugzilla.redhat.com\/bugzilla\/show_bug.cgi?id=147533\r\n*\/\r\n#\tif !defined(CMSPAR)\r\n#\t\tdefine CMSPAR 010000000000\r\n#\tendif \/* CMSPAR *\/\r\n#\t\r\n#\tdefine DEVICEDIR \"\/dev\/\"\r\n#\tdefine LOCKDIR \"\/var\/lock\"\r\n#\tdefine LOCKFILEPREFIX \"LCK..\"\r\n#\tdefine FHS\r\n#endif \/* __linux__ *\/<\/pre>\n
Which is odd<\/em> because I see a few threads about how nrjavaserial has been updated and as soon as the newer nrjavaserial gets bundled into the application, locking will all be sorted. And there’s an open issue<\/a> for exactly the problem we are having … which explains why I’m not seeing something different<\/em> in their source code. Digging around more, it looks like they didn’t actually change the hardcoded paths but rather added support for liblockdev. Which prompted my hypothesis that simply installing the lockdev package would magically sort the issue. It did not.<\/p>\n
In the interim, though, we can just add write permission for \/run\/lock thorough the config file \/usr\/lib\/tmpfiles.d\/legacy.conf — the distro creates the lock directory owned by root:root. Original config lines:<\/p>\n
d \/run\/lock 0755 root root -\r\nL \/var\/lock - - - - ..\/run\/lock<\/pre>\n
We can create the folder as owned by the lock group group and add group write permissions (realizing that creates the potential for privilege escalation attacks). Updated config lines:<\/p>\n
#d \/run\/lock 0755 root root -\r\nd \/run\/lock 0775 root lock -\r\nL \/var\/lock - - - - ..\/run\/lock<\/pre>\n
Adding the openhab account to the lock group allows the LCK.. files to be created.<\/p>\n
[lisa@server run]# usermod -a -G lock openhab\r\n[lisa@server run]# id openhab\r\nuid=964(openhab) gid=963(openhab) groups=963(openhab),5(tty),18(dialout),54(lock)<\/pre>\n
Either reboot to reprocess legacy.conf or manually change the ownership & permissions on \/run\/lock. Either way, confirm that the changes are successful.<\/p>\n
[lisa@server run]# chown root:lock \/run\/lock\r\n[lisa@server run]# chmod g+w lock\r\n[lisa@server lock]# ll \/run | grep lock\r\ndrwxrwxr-x  7 root           lock             200 Aug 13 14:03 lock\r\n\r\n<\/pre>\n
If you manually set the permissions, restart openHAB. Our devices are online, and we have lock files:<\/p>\n
[lisa@seerver lock]# ll\r\ntotal 12\r\n-rw-r--r-- 1 root root 22 Aug 10 15:35 asound.state.lock\r\ndrwx------ 2 root root 60 Aug 10 15:30 iscsi\r\n-rw-r--r-- 1 openhab openhab 11 Aug 13 14:03 LCK..ttyUSB-5\r\n-rw-r--r-- 1 openhab openhab 11 Aug 13 14:03 LCK..ttyUSB-55\r\ndrwxrwxr-x 2 root lock 40 Aug 10 15:30 lockdev\r\ndrwx------ 2 root root 40 Aug 10 15:30 lvm\r\ndrwxr-xr-x 2 root root 40 Aug 10 15:30 ppp\r\ndrwxr-xr-x 2 root root 40 Aug 10 15:30 subsys<\/pre>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
I’ll prefix this saga with the fact my sad story is implementation specific (i.e. relevant to those using Fedora, RHEL, or CentOS). I know Ubuntu has its own history with handling locks, and I’m sure other distros do as well. But I don’t know the history there, nor do I know how they currently manage …<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[63,30],"tags":[638,44,394,637],"class_list":["post-3329","post","type-post","status-publish","format-standard","hentry","category-home-automation","category-system-administration","tag-lockdev","tag-openhab","tag-openhab2","tag-rxtx"],"_links":{"self":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/3329","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3329"}],"version-history":[{"count":5,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/3329\/revisions"}],"predecessor-version":[{"id":3338,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=\/wp\/v2\/posts\/3329\/revisions\/3338"}],"wp:attachment":[{"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3329"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3329"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rushworth.us\/lisa\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3329"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}