fleetctl using wildcards can be dangerous #710
Comments
|
@bcwaldon , I checked the code, in main() function, os.Exit(cmd.Run(cmd.Flags.Args())), cmd.Flags.Args() function call will find the file using wildcards in current directory. I think should not give the array of units to cmd.Run. Need search from etcd/http client , then pass it to cmd.Run. |
|
@bcwaldon , If need modify as what I suggest, I can help to implement. |
Curerntly, fleetctl destroy *.service, it will search the units
in the local directory. The args with wildcards have already parsed
by golang package before be passed into runDestroyUnits. So
runDestroyUnits cannot do anything.
This patch support wildcards just search in the repository,
not from local directory. But need support a new interface. The new
interface is:
fleetctl destroy "xx*.service".
We found that if bracket the service name, the arg will not be
parsed by golang package to local directory. Then we can do match it
with the service name in the repository.
Fixes coreos#710
Curerntly, fleetctl destroy *.service, it will search the units
in the local directory. The args with wildcards have already parsed
by golang package before be passed into runDestroyUnits. So
runDestroyUnits cannot do anything.
This patch support wildcards just search in the repository,
not from local directory. But need support a new interface. The new
interface is:
fleetctl destroy "xx*.service".
We found that if bracket the service name, the arg will not be
parsed by golang package to local directory. Then we can do match it
with the service name in the repository.
Fixes coreos#710
|
@bcwaldon @jonboulle , I have given the patch. Do you have any comment ? |
Curerntly, fleetctl destroy *.service, it will search the units
in the local directory. The args with wildcards have already parsed
by golang package before be passed into runDestroyUnits. So
runDestroyUnits cannot do anything.
This patch support wildcards just search in the repository,
not from local directory. But need support a new interface. The new
interface is:
fleetctl destroy "xx*.service".
We found that if bracket the service name, the arg will not be
parsed by golang package to local directory. Then we can do match it
with the service name in the repository.
Fixes coreos#710
|
Let's try shepherd this change in for v0.13.0 |
|
This is not entirely clear: but it seems like @developerinlondon assumed the undesired file globbing was performed by fleetctl itself (hello Windows...) -- whereas it's in fact performed by the shell. As such, I guess this bug qualifies as invalid. The linked PR on the other hand proposes adding globbing of units within fleetctl -- which is an entirely new feature; and is only marginally related to the actual problem at hand IMHO... Having said that, it sounds fairly useful on it's own -- but it needs quite some work. (See my comment over there.) |
currently using wildcards with
fleetctl destroy xpicks up the filenames from the current directory instead of whats shown infleetctl list-unitsthis can be dangerous as the current directory does not necessarily reflect whats in list-units.
the correct behaviour might be to use the wildcards for units that are already there or not accept wildcards at all.
The text was updated successfully, but these errors were encountered: