@BryanS @attila
I spent some time debugging this and discovered that the Adept Runtime is receiving EACCES when trying to open files with read/write permission in "/tmp". The following call results in -1 being returned when the file already exists and was created by another user, other than root:
open("/tmp/digilent-adept2-shm-dvtbl", O_CREAT | O_RDWR, S_IRWXU | S_IRWXG | S_IRWXO );
This will ultimately lead to error code 3090 (initialization failed) because we use these files for locking while performing certain operations and if they can't be opened then the system won't function correctly.
The "/tmp" directory has permissions 1777, meaning the sticky bit is set. This means that all users have read, write, and execute permissions for all files in "/tmp" but only root or the user that created a file in "/tmp" may delete it. This is fine since our software doesn't delete the files that it creates in "/tmp". After seeing the EACCES error I decided to run some experiments using 3 different user accounts: "malexander", "adept", and "root".
Test 1: Ubuntu 20 LTS with sticky bit set for "/tmp"
1. As user "adept" execute "touch /tmp/blah.txt"
2. As user "adept" execute "chmod 777 /tmp/blah.txt"
3. As user "malexander" execute "echo "test" > /tmp/blah.txt" and receive "-bash: /tmp/blah.txt: Permission denied"
4. As user "root" execute "echo "test" > /tmp/blah.txt" and receive "-bash: /tmp/blah.txt: Permission denied"
5. As user "adept" execute "rm /tmp/blah.txt" to remove the file
6. As user "root" execute "touch /tmp/blah.txt" and "chmod 777 /tmp/blah.txt"
7. As user "malexander" execute "echo "test" > /tmp/blah.txt" and receive no error.
8. As user "adept" execute "echo "test2" >> /tmp/blah.txt" and receive no error.
9. As user "adept" cat file "/tmp/blah.txt" and see the expected text:
test
test2
10. As "root" execute "rm /tmp/blah.txt"
Test 2: Ubuntu 20 LTS with sticky bit cleared for "/tmp"
1. As user "root" execute "chmod 777 /tmp" to remove sticky bit
2. As user "adept" execute "touch /tmp/blah.txt" followed by "adept" execute "chmod 777 /tmp/blah.txt"
3. As user "malexander" execute "echo "test" > /tmp/blah.txt" and receive no error.
4. As user "root" execute "echo "test2" >> /tmp/blah.txt" and receive no error.
5. As user "adept" cat file "/tmp/blah.txt" and see the expected text:
test
test2
Test 3: On Ubuntu 20 LTS run Adept test suite DmgrEnumExt test from multiple user accounts without removing the files in "/tmp" between runs with sticky bit off.
1. First make sure that no adept files are presently in the /tmp dir by executing "rm /tmp/digilent*" as root
2. As user "adept" execute "./test DmgrEnumEx -w 2000" and get expected result:
0: ADP3450-1
Transport Type: TCPIP
Hostname: 10.1.112.148
IP Address: 10.1.112.148
Port: 33890
Account:
Password:
UsrName: ADP3450-1
ProdName: Analog Discovery Pro 3450
SN: SN:210018AFF319
MAC Address: MAC:00-18-3E-03-94-5E
DCAP: 00000008
PDID: 40720410
PASS
3. As user "malexander" execute "./test DmgrEnumEx -w 2000" and get expected result:
0: ADP3450-1
Transport Type: TCPIP
Hostname: 10.1.112.148
IP Address: 10.1.112.148
Port: 33890
Account:
Password:
UsrName: ADP3450-1
ProdName: Analog Discovery Pro 3450
SN: SN:210018AFF319
MAC Address: MAC:00-18-3E-03-94-5E
DCAP: 00000008
PDID: 40720410
PASS
Test 4: On Ubuntu 18 repeat test 1 with the sticky bit enabled (default on startup). The results under Ubuntu 18 were different. Any user can write a file that was created by another user in "/tmp" as long as the permissions for the file are set to 777. This is the behavior I expected.
Test 5: On Ubuntu 16 repeat test 1 with the sticky bit enabled (default on startup). The results under Ubuntu 18 were different. Any user can write a file that was created by another user in "/tmp" as long as the permissions for the file are set to 777. This is the behavior I expected.
Conclusion:
I think this issue is the result of a bug in Ubuntu 20. Sure, it's possible that the behavior in Ubuntu 16 and Ubuntu 18 is the result of a bug that was fixed in Ubuntu 20. However, I think that's unlikely since we've never received reports of this issue on any other distribution. Further, the code that's being executed hasn't changed in years.
I'm not sure who to contact about this issue to get it fixed upstream in Ubuntu 20 but I'll try to find someone.
For now the only workaround I can suggest for people running Ubuntu 20 is to execute "chmod 777 /tmp" as root on startup to remove the sticky bit.
