https://github.com/osquery/osquery logo
Join Slack
Powered by
It stands to reason that `sudo orbit shell` should...
# fleet
a
It stands to reason that 
sudo orbit shell
should be runnable multiple times on the same system without additional configuration, right? So any idea why I’d be getting the error
Copy code
create osquery runner: apply option: initialize osquery data path: Path /opt/orbit/shell already exists with mode 20000000750 instead of the expected 20000000755
After Ctrl+D’ing out of 
sudo orbit shell
and retrying it the second time? More in the thread. (Fleet 4.73.4; Debian 13) TL;DR, I shouldn’t have to 
chmod 0755 /opt/orbit/shell
to use the osquery shell -- optionally creating the directory first to avoid needing to do it after -- so should I cut an issue on the Fleet GitHub for this, or am I missing something here?
I am building the 
fleetd.deb
package using the following, which is effectively just running it in the docker container (because running it outside gave me another error):
Copy code
- name: configure_fleet | build_fleetd_agent | Build the fleetd agent
  ansible.builtin.command:
    cmd: >
      docker run
      --mount type=bind,src=/opt/corp/fleetdm/fleetd,dst=/build
      --rm
      {{ fleetdm_official_fleetctl_docker_image_name }}
      package
      --type=deb --enable-scripts
      --fleet-url=https://{{ fleetdm_web_addr }} --enroll-secret={{ fleetdm_osquery_enroll_secret }}
      --outfile fleetd-{{ fleetdm_web_addr | split(":") | first }}.deb

"The other error"
me@boardwalk-test-0000:~/tmp$ fleetctl package --type=deb
Generating your fleetd agent...
Error: create orbit dir: Path /tmp/orbit-package775645894/root already exists with mode 20000000750 instead of the expected 20000000755
Which builds an installable copy of 
fleet-osquery
. So far so good. Running 
sudo orbit shell
brings up the osquery shell, after which I control+D out:
Copy code
me@boardwalk-test-0000:/opt$ sudo orbit shell --debug
{"level":"debug","path":"/opt/orbit/bin/osqueryd/linux/stable/osqueryd","target":"osqueryd","time":"2025-11-04T20:42:02Z","message":"found expected target locally"}
{"level":"info","cmd":"/opt/orbit/bin/osqueryd/linux/stable/osqueryd -S --pidfile=/opt/orbit/shell/osquery.pid --extensions_socket=/opt/orbit/shell/orbit-osquery.em --database_path /opt/orbit/shell/osquery.db --tls_server_certs /opt/orbit/certs.pem","time":"2025-11-04T20:42:02Z","message":"start osqueryd"}
{"level":"debug","time":"2025-11-04T20:42:02Z","message":"start osqueryd extension runner"}
Using a virtual database. Need help, type '.help'
osquery> {"level":"debug","time":"2025-11-04T20:42:02Z","message":"extension manager checked"}

osquery> 

{"level":"info","time":"2025-11-04T20:42:07Z","message":"interrupt osqueryd extension runner"}
Then attempting to re-enter:
Copy code
me@boardwalk-test-0000:~/tmp$ sudo orbit shell --debug
{"level":"debug","path":"/opt/orbit/bin/osqueryd/linux/stable/osqueryd","target":"osqueryd","time":"2025-11-04T20:42:10Z","message":"found expected target locally"}
{"level":"error","error":"create osquery runner: apply option: initialize osquery data path: Path /opt/orbit/shell already exists with mode 20000000750 instead of the expected 20000000755","time":"2025-11-04T20:42:10Z","message":"run orbit failed"}
stat
confirms the permission, and if I manually edit the permissions to 
0755
, using 
orbit shell
works from then-on, but having to manually edit permissions like this feels like a bug:
Copy code
me@boardwalk-test-0000:~/tmp$ stat /opt/orbit/shell/
  File: /opt/orbit/shell/
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 254,1	Inode: 2752561     Links: 3
Access: (0750/drwxr-x---)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-11-04 20:42:02.342686522 +0000
Modify: 2025-11-04 20:42:07.546622919 +0000
Change: 2025-11-04 20:42:07.546622919 +0000
 Birth: 2025-11-04 20:42:02.342686522 +0000
me@boardwalk-test-0000:~/tmp$ sudo chmod 0755 /opt/orbit/shell/
me@boardwalk-test-0000:~/tmp$ sudo orbit shell --debug
{"level":"debug","path":"/opt/orbit/bin/osqueryd/linux/stable/osqueryd","target":"osqueryd","time":"2025-11-04T20:45:15Z","message":"found expected target locally"}
{"level":"info","cmd":"/opt/orbit/bin/osqueryd/linux/stable/osqueryd -S --pidfile=/opt/orbit/shell/osquery.pid --extensions_socket=/opt/orbit/shell/orbit-osquery.em --database_path /opt/orbit/shell/osquery.db --tls_server_certs /opt/orbit/certs.pem","time":"2025-11-04T20:45:15Z","message":"start osqueryd"}
{"level":"debug","time":"2025-11-04T20:45:15Z","message":"start osqueryd extension runner"}
Using a virtual database. Need help, type '.help'
osquery> {"level":"debug","time":"2025-11-04T20:45:16Z","message":"extension manager checked"}

osquery> 

{"level":"info","time":"2025-11-04T20:45:20Z","message":"interrupt osqueryd extension runner"}
Also for the sake of completeness, I tried upgrading Fleet to v4.75.1, and the same behavior was seen after regenerating, purging, and reinstalling 
fleet-osquery
.
k
That’s definitely odd behavior. Was the package generated as root?
a
Well, the package was generated in the context of the 
fleetdm/fleetctl:v4.75.1
docker image, then written to a bind mount to the host; the layers set don’t seem to set the user to non-root, so it should have been generated as root.
Also the docker host is not set up for rootless execution of 
docker
, so the invocation was done via 
sudo docker
, which as I understand it results in the running application operating in root’s context, unless the image has a layer to strip root (which here, it does not).
24 Views
Open in Slack
PreviousNext
Powered by