#Mysterious error message

1 messages ยท Page 1 of 1 (latest)

quick yew
#

๐Ÿงต

#

Context: I really need the ability to call core functions from the CLI, so made a wrapper module to enable it

quick yew
#

I fixed it with the following patch to dagger:

diff --git a/cmd/dagger/functions.go b/cmd/dagger/functions.go
index d5f48f3fb..24f49fcf6 100644
--- a/cmd/dagger/functions.go
+++ b/cmd/dagger/functions.go
@@ -564,7 +564,8 @@ func (fc *FuncCommand) addArgsForFunction(cmd *cobra.Command, cmdArgs []string,
     for _, arg := range fn.Args {
         _, err := arg.AddFlag(cmd.Flags(), dag)
         if err != nil {
-            return err
+            // return err
+            continue
         }
         if !arg.TypeDef.Optional {
             cmd.MarkFlagRequired(arg.FlagName())
@@ -606,6 +607,7 @@ func (fc *FuncCommand) selectFunc(selectName string, fn *modFunction, cmd *cobra
 
         flag := cmd.Flags().Lookup(arg.FlagName())
         if flag == nil {
+            return nil
             return fmt.Errorf("no flag for %q", arg.FlagName())
         }
 
cobalt sentinel
#

This is another type we just need to add handling for in the CLI. Similar to how dir+file args are interpreted as paths, we should probably just add support for interpreting args of that type as paths to unix socks on the host.

(This comment is related, though the issue is technically for something slightly different: https://github.com/dagger/dagger/issues/6726#issuecomment-1963586621)

#

This is almost super trivial to implement to the point I would try to get in for v0.10.0, but it's non-obvious what the cache key should be for these. Local dirs+files are obvious (content hash), but a unix socket less so... I'll either open a draft PR or at least an issue

quick yew
#

what's weird is that I only exposed core types.

#

I done know how the CLI found its way to introspecting git() which is where that socket argument is defined

#

but yeah I can make this a small contribution to the cli, feels within my reach

cobalt sentinel
cobalt sentinel
# quick yew but yeah I can make this a small contribution to the cli, feels within my reach

I actually started taking a stab at it already, the CLI part is indeed completely trivial but the engine-side part is extra tricky. The most naive way of doing it would actually result in creating a backdoor where any module could gain access to any unix socket on the host (i.e. /var/run/docker/docker.sock). They'd have to really be malicious and either craft IDs by hand and/or make raw gql requests, but that still feels like a door worth leaving closed.

We can stop it but it'll require careful tracking of which module is "allowed" access to a unix socket (based on being explicitly pass it as an arg). Which isn't too huge an effort but kind of intricate. So I'm going to just open an issue for now as to not get too bogged down in the midst of the release priorities ๐Ÿ™‚

cobalt sentinel
#

Well actually on closer look it seems that door is accidentally open atm... you do have to go way out of your way but it would be possible for a module to make a raw gql request to create a host socket and then get access to that socket on the original caller's host ๐Ÿ˜ตโ€๐Ÿ’ซ So actually, gonna patch that up quick and then create the follow-up issue for properly+securely supporting this

cobalt sentinel