OS-7433: lxbrand openat(2) should behave same as Linux's when O_PATH and O_NOFOLLOW are specified

Details

Issue Type:Bug
Priority:3 - Elevated
Status:Resolved
Created at:2018-12-06T19:43:16.757Z
Updated at:2019-05-24T19:53:04.238Z

People

Created by:Former user
Reported by:Former user
Assigned to:Former user

Resolution

Fixed: A fix for this issue is checked into the tree and tested.
(Resolution Date: 2019-03-06T16:58:11.519Z)

Fix Versions

2019-03-14 Night Cheese (Release Date: 2019-03-14)

Related Issues

Labels

lxbrand

Description

After upgrading ubuntu-16.04/LX (8879c758-c0da-11e6-9e4b-93e32a67e805) systemd-tmpfiles-setup.service failed with the below error message.

root@922ae660-b54a-efe3-e45b-868b087a81ff:~# systemctl status systemd-tmpfiles-setup.service 
● systemd-tmpfiles-setup.service - Create Volatile Files and Directories 
Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static; vendor preset: enabled) 
Active: failed (Result: exit-code) since Wed 2018-11-21 10:26:17 UTC; 1min 34s ago 
Docs: man:tmpfiles.d(5) 
man:systemd-tmpfiles(8) 
Process: 111360 ExecStart=/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev (code=exited, status=1/FAILURE) 
Main PID: 111360 (code=exited, status=1/FAILURE)

Nov 21 10:26:17 922ae660-b54a-efe3-e45b-868b087a81ff systemd-tmpfiles[111360]: Failed to validate path /var/run/sshd: Too many levels of symbolic links 
Nov 21 10:26:17 922ae660-b54a-efe3-e45b-868b087a81ff systemd-tmpfiles[111360]: Failed to validate path /var/run/sudo: Too many levels of symbolic links 
Nov 21 10:26:17 922ae660-b54a-efe3-e45b-868b087a81ff systemd-tmpfiles[111360]: Failed to validate path /var/run/sudo/ts: Too many levels of symbolic links

strace showed openat() failing

openat(4, "run", O_RDONLY|O_NOFOLLOW|O_CLOEXEC|O_PATH) = -1 ELOOP (Too many levels of symbolic links)

A similar issue has been reported in OmniOS

https://github.com/omniosorg/illumos-omnios/issues/331

Comments

Comment by Former user
Created at 2018-12-20T19:46:48.800Z

@accountid:624b27045f63fd0069b53cd6 - Are you currently working on this issue? If not, do you know if there is anyone who is currently working on it?


Comment by Former user
Created at 2018-12-21T00:10:50.360Z

Thank you Patrick.


Comment by Former user
Created at 2019-03-05T15:05:39.412Z

@accountid:62561aa213c2c8006a35f07b said he would take a look at this today. I don't expect him to fix it, but his input as to how it may be fixed would be helpful.


Comment by Former user
Created at 2019-03-05T21:51:12.435Z

I looked at the OmniOS fix here:
https://github.com/omniosorg/illumos-omnios/pull/337/commits/0c4c3164bd0d5a3176128db2224a0b941df18573

This seems reasonable and I think we could just pull that in.


Comment by Former user
Created at 2019-03-05T22:35:26.248Z

Testing: I pulled in the fix from omniosce. I did a build and ran it in coal. Without the fix, I saw the sshd failure. With the fix, all is well.


Comment by Former user
Created at 2019-03-06T16:15:44.684Z

More testing:

I ran ltp per the instructions in usr/src/lib/brand/lx/testing/Readme_ltp. Aside from some timing issues ("slept for too long") due to running under vmware and unrelated issues described in OS-7636 and OS-7640, all went well.

Once the right version of ltp was being used, the failures were:

root@7c5eb456-134f-49d5-a9f4-845bd48c8161:~# grep ': FAIL: ' /tmp/test.log
tst_timer_test.c:321: FAIL: clock_nanosleep() slept for too long
tst_timer_test.c:321: FAIL: clock_nanosleep() slept for too long
tst_timer_test.c:321: FAIL: clock_nanosleep() slept for too long
tst_timer_test.c:321: FAIL: clock_nanosleep() slept for too long
tst_timer_test.c:321: FAIL: clock_nanosleep() slept for too long
tst_timer_test.c:321: FAIL: epoll_wait() slept for too long
tst_timer_test.c:321: FAIL: epoll_wait() slept for too long
tst_timer_test.c:321: FAIL: epoll_wait() slept for too long
tst_timer_test.c:321: FAIL: epoll_wait() slept for too long
io_setup01.c:60: FAIL: io_setup() failed unexpectedly, returned -EINVAL expected -EAGAIN/EWOULDBLOCK
tst_timer_test.c:321: FAIL: nanosleep() slept for too long
tst_timer_test.c:321: FAIL: nanosleep() slept for too long
tst_timer_test.c:321: FAIL: nanosleep() slept for too long
tst_timer_test.c:321: FAIL: nanosleep() slept for too long
tst_timer_test.c:321: FAIL: pselect() slept for too long
tst_timer_test.c:321: FAIL: pselect() slept for too long
tst_timer_test.c:321: FAIL: pselect() slept for too long
tst_timer_test.c:321: FAIL: pselect() slept for too long
tst_timer_test.c:321: FAIL: pselect() slept for too long
tst_timer_test.c:321: FAIL: pselect() slept for too long
tst_timer_test.c:321: FAIL: pselect() slept for too long
tst_timer_test.c:321: FAIL: pselect() slept for too long
tst_timer_test.c:321: FAIL: pselect() slept for too long
tst_timer_test.c:321: FAIL: select() slept for too long
tst_timer_test.c:321: FAIL: select() slept for too long
tst_timer_test.c:321: FAIL: select() slept for too long
tst_timer_test.c:321: FAIL: select() slept for too long
tst_timer_test.c:321: FAIL: futex_wait() slept for too long
tst_timer_test.c:321: FAIL: futex_wait() slept for too long
tst_timer_test.c:321: FAIL: futex_wait() slept for too long
tst_timer_test.c:321: FAIL: futex_wait() slept for too long

Comment by Jira Bot
Created at 2019-03-06T16:51:14.126Z

illumos-joyent commit 14d41c42063f1945d4c7eaa88981237b8bee704c (branch master, by Andy Fiddaman)

OS-7433 lxbrand openat(2) should behave same as Linux's when O_PATH and O_NOFOLLOW are specified
Reviewed by: Patrick Mooney <patrick.mooney@joyent.com>
Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>
Approved by: Jerry Jelinek <jerry.jelinek@joyent.com>