Home

Forums

Stories

Knowledge Base

Business Community > WiFi > Files in Omada_Controller_v3.2.6_linux_x64_deb are owned by uid 1001

< WiFi

Files in Omada_Controller_v3.2.6_linux_x64_deb are owned by uid 1001

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

Files in Omada_Controller_v3.2.6_linux_x64_deb are owned by uid 1001

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

ASCII

2020-01-30 00:47:01

Posts: 74

Helpful: 18

Solutions: 1

Stories: 0

Registered: 2020-01-11

Files in Omada_Controller_v3.2.6_linux_x64_deb are owned by uid 1001

2020-01-30 00:47:01

Looks like the .deb was not built properly and the files shipped in the Debian archive are owned by 1001:1001

# ls -la /opt/tplink/EAPController/
drwxrwxr-x 11 1001 1001 4096 Jan 30 01:42 .
drwxrwxr-x 3 1001 1001 4096 Jan 30 01:42 ..
drwxrwxr-x 2 1001 1001 4096 Jan 30 01:42 bin
drwxrwxr-x 7 omada omada 4096 Jan 30 01:42 data
drwxr-xr-x 5 1001 1001 4096 Jan 30 01:42 jre
drwxrwxr-x 2 1001 1001 4096 Jan 30 01:42 keystore
drwxrwxr-x 2 1001 1001 12288 Jan 30 01:42 lib
drwxr-x--- 2 omada omada 4096 Jan 30 01:42 logs
drwxrwxr-x 2 1001 1001 4096 Jan 30 01:42 properties
drwxrwxr-x 2 1001 1001 4096 Jan 30 01:42 webapps
drwxr-x--- 3 omada omada 4096 Jan 30 01:42 work

Those files should be owned by root:root

2 Reply

ASCII

LV2

2020-01-30 00:47:41

Posts: 74

Helpful: 18

Solutions: 1

Stories: 0

Registered: 2020-01-11

Re:Files in Omada_Controller_v3.2.6_linux_x64_deb are owned by uid 1001

2020-01-30 00:47:41

ASCII wrote

Those files should be owned by root:root

Those files == the files with 1001:1001

R1D2

LV6

2020-01-30 18:30:48 - last edited 2020-01-30 18:40:12

Posts: 4334

Helpful: 1039

Solutions: 173

Stories: 3

Registered: 2015-12-05

Re:Files in Omada_Controller_v3.2.6_linux_x64_deb are owned by uid 1001

2020-01-30 18:30:48 - last edited 2020-01-30 18:40:12

@ASCII,

I suggest to use the community version.

It assigns correct ownership to files & directories and implements Privilege Separation much more strictly than the official version does:

$ ls -l OmadaController
total 24
-rw-r--r-- 1 root root 614 Jan 16 17:42 CONFIG
drwxrwx--- 2 root omadad 6 Jan 16 17:42 backup
drwxr-xr-x 2 root root 19 Jan 16 17:58 bin
drwxr-xr-x 7 omadad omadad 74 Jan 30 00:11 data
drwxr-x--- 2 root omadad 39 Jan 16 17:58 keystore
drwxr-xr-x 2 root root 8192 Jan 16 17:58 lib
drwxr-xr-x 2 omadad omadad 4096 Jan 30 00:10 logs
drwxr-x--- 2 root omadad 4096 Jan 30 00:11 properties
drwxr-xr-x 2 root root 36 Jan 16 17:58 webapps
drwxr-xr-x 3 omadad omadad 32 Jan 30 00:11 work
$

If Omada controller wouldn't remove and create the work directory on each start, even the OmadaController top-level directory could be assigned ownership of root (as it should be). So it needs to be owned by user omadad, which bears some risks:

$ ls -Lld OmadaController
drwxr-xr-x 12 omadad omadad 155 Jan 17 19:50 OmadaController

༺ 0100 1101 0010 10ཏ1 0010 0110 1010 1110 ༻

Files in Omada_Controller_v3.2.6_linux_x64_deb are owned by uid 1001

Files in Omada_Controller_v3.2.6_linux_x64_deb are owned by uid 1001

Information

Voters 0

Tags