#Mysterious error message
1 messages ยท Page 1 of 1 (latest)
๐งต
Context: I really need the ability to call core functions from the CLI, so made a wrapper module to enable it
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())
}
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
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
I think it's just because you returned Git here: https://github.com/shykes/daggerverse/blob/21b2cfeac8717b9e11bb21336374eabae702fc84/core/main.go#L12
The engine is just following that type and hitting the API that asks for Socket as an input.
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 ๐
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
FTR, this is the PR that plugs that existing hole: https://github.com/dagger/dagger/pull/6748
And the issue for following up with proper support for all this: https://github.com/dagger/dagger/issues/6747