varlink / rust Goto Github PK

View Code? Open in Web Editor NEW

60.0 60.0 13.0 1.06 MB

Rust implementation of the Varlink protocol

Home Page: https://docs.rs/varlink/

License: Apache License 2.0

Rust 100.00%

rust varlink

rust's Introduction

The varlink.org Website

rust's People

Contributors

Stargazers

Watchers

Forkers

fabiand tasleson ignatenkobrain katharostech haraldh curiousleo ecarrara sftim atul9 isgasho icodein iq-scm zeenix

rust's Issues

include LICENSE-* into varlink-cli crate

Apache-2.0 requires text license to be present along with source, but archive on crates.io doesn't have it.

API for passing file descriptors

Perhaps I'm missing something but there doesn't seem to be a way to pass FDs? 🤔

Recommended Way to Shutdown Varlink Server?

Is there a recommended way to shutdown the Varlink server when it is started with varlink::listen()?

I'm sure I could find a way to do it if I implemented the server myself, I was just making sure that there wasn't already a good way to do it.

Specifically I am looking to be able to shutdown the server in response to an RPC call, if that changes anything.

client: consume the connection until send+recv complete

Instead of .take() for read and write stream, maybe just consume the connection and return it after success and disallow clone() for the connection

Parser error

I'm unable to generate bindings for io.podman.

error: failed to run custom build command for `podman-dapi v0.1.0 (file:///home/marcin.skarbek/projects/podman-dapi)`
process didn't exit successfully: `/home/marcin.skarbek/projects/podman-dapi/target/debug/build/podman-dapi-063e827264695f43/build-script-build` (exit code: 1)
--- stderr
Could not generate rust code from varlink file `src/io.podman.varlink`: Parse Error

With go-varlink code generation works fine so I assume that it has to be rust parser problem.

varlink 3.1.0 broke API

   Compiling varlink-cli v2.1.2 (file:///builddir/build/BUILD/varlink-cli-2.1.2)
     Running `/usr/bin/rustc --crate-name varlink src/main.rs --crate-type bin --emit=dep-info,link -C opt-level=3 -C metadata=842203fd494b0d7f -C extra-filename=-842203fd494b0d7f --out-dir /builddir/build/BUILD/varlink-cli-2.1.2/target/release/deps -L dependency=/builddir/build/BUILD/varlink-cli-2.1.2/target/release/deps --extern clap=/builddir/build/BUILD/varlink-cli-2.1.2/target/release/deps/libclap-a4c1fb588dc269ad.rlib --extern failure=/builddir/build/BUILD/varlink-cli-2.1.2/target/release/deps/libfailure-70ad11ba8ee3a65b.rlib --extern failure_derive=/builddir/build/BUILD/varlink-cli-2.1.2/target/release/deps/libfailure_derive-9059b94b0407baf1.so --extern serde=/builddir/build/BUILD/varlink-cli-2.1.2/target/release/deps/libserde-ee1248841efe888e.rlib --extern serde_json=/builddir/build/BUILD/varlink-cli-2.1.2/target/release/deps/libserde_json-223f91055e8f3fde.rlib --extern varlink=/builddir/build/BUILD/varlink-cli-2.1.2/target/release/deps/libvarlink-2fee983ca4ed6501.rlib --extern varlink_parser=/builddir/build/BUILD/varlink-cli-2.1.2/target/release/deps/libvarlink_parser-3f319b479e62ca66.rlib --extern varlink_stdinterfaces=/builddir/build/BUILD/varlink-cli-2.1.2/target/release/deps/libvarlink_stdinterfaces-3e7c5e0b2ef22076.rlib -Copt-level=3 -Cdebuginfo=2 -Clink-arg=-Wl,-z,relro,-z,now -L native=/builddir/build/BUILD/varlink-cli-2.1.2/target/release/build/backtrace-sys-056eea41ad9a5097/out`
error[E0609]: no field `upgraded` on type `varlink::Reply`
   --> src/proxy.rs:122:34
    |
122 |                 upgraded = reply.upgraded.unwrap_or(false);
    |                                  ^^^^^^^^ unknown field
    |
    = note: available fields are: `continues`, `error`, `parameters`
error[E0609]: no field `upgraded` on type `varlink::Reply`
   --> src/proxy.rs:228:34
    |
228 |                 upgraded = reply.upgraded.unwrap_or(false);
    |                                  ^^^^^^^^ unknown field
    |
    = note: available fields are: `continues`, `error`, `parameters`

Access SO_PASSCRED credentials in handler

While writing a backend for systemd-userdbd, which uses Varlink, I need to authorize user access to the Varlink service depending on the credentials passed over the Unix socket using SO_PASSCRED.

I am not sure how to best do that. Two options that come to mind are:

Pass the socket to the handler method – in that case, I could try to get the SO_PASSCRED message directly
Support SO_PASSCRED (and SO_PEERCRED) natively in the Varlink crate, and provide an interface to determine client credentials

Some advice or thoughts on how it could be done would be welcome.

Question: which license can I use for varlink_grammar.peg

https://github.com/varlink/rust/blob/master/varlink_parser/src/varlink_grammar.peg

Can I choose one from MIT or APACHE?

use the error_chain crate for errors

https://crates.io/crates/error-chain might give better error reporting up the stack

Provide listen() variant that accepts listener

In order to use systemd socket activation, it would be good to provide a variant of listen that, instead of an address string, accepts a Listener.

use the quote crate in generator.rs

Maybe using the quote! macro from https://crates.io/crates/quote makes code generation more readable.

Please expand `varlink::ListenConfig` to support socker permission

In order to allowing everyone to talk to varlink socket file, I would like to set the socket file permission to 0666.

The possible ways I found is:

Implement varlink::VarlinkService::handle by myself.
Use service activator, still trying, not sure it works or not.

Can you expand ListenConfig so that varlink::listen() could set it?

null is not deserialized correctly

Using this with Podman will result in invalid type: null, expected a sequence on many endpoints, as empty lists are omitted in favor of null.

I'm not sure if this is an issue in my usage or some change within Serde.

Error Type From Generated Client Not Sync + Send

Hello there. I am trying to propagate an error with the ? operator from a client call(), but I am getting a compiler error because the error type isn't Sync + Send:

error[E0277]: `(dyn std::error::Error + 'static)` cannot be sent between threads safely
  --> src/cli/daemon/run_hook.rs:26:53
   |
26 |     service.run_hook("test-hook".to_string()).call()?;
   |                                                     ^ `(dyn std::error::Error + 'static)` cannot be sent between threads safely
   |
   = help: the trait `std::marker::Send` is not implemented for `(dyn std::error::Error + 'static)`
   = note: required because of the requirements on the impl of `std::marker::Send` for `std::ptr::Unique<(dyn std::error::Error + 'static)>`
   = note: required because it appears within the type `std::boxed::Box<(dyn std::error::Error + 'static)>`
   = note: required because it appears within the type `std::option::Option<std::boxed::Box<(dyn std::error::Error + 'static)>>`
   = note: required because it appears within the type `rpc::lucky_rpc::Error`
   = note: required because of the requirements on the impl of `std::convert::From<rpc::lucky_rpc::Error>` for `anyhow::Error`
   = note: required by `std::convert::From::from`

error[E0277]: `(dyn std::error::Error + 'static)` cannot be shared between threads safely
  --> src/cli/daemon/run_hook.rs:26:53
   |
26 |     service.run_hook("test-hook".to_string()).call()?;
   |                                                     ^ `(dyn std::error::Error + 'static)` cannot be shared between threads safely
   |
   = help: the trait `std::marker::Sync` is not implemented for `(dyn std::error::Error + 'static)`
   = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<(dyn std::error::Error + 'static)>`
   = note: required because it appears within the type `std::boxed::Box<(dyn std::error::Error + 'static)>`
   = note: required because it appears within the type `std::option::Option<std::boxed::Box<(dyn std::error::Error + 'static)>>`
   = note: required because it appears within the type `rpc::lucky_rpc::Error`
   = note: required because of the requirements on the impl of `std::convert::From<rpc::lucky_rpc::Error>` for `anyhow::Error`
   = note: required by `std::convert::From::from`

error: aborting due to 2 previous errors

For more information about this error, try `rustc --explain E0277`.
error: could not compile `lucky`

Is there anything that I can do about this? I don't have a great understanding of why this is happening, so I don't know what my options are.

To be clear run_hook is my RPC method and "test-hook".to_string() is the expected argument.

test_generate fails with recent rust stack

---- test_generate stdout ----
cargo:rerun-if-changed=tests/org.example.complex.varlink
thread 'test_generate' panicked at 'Generated files differ: 'tests/org.example.complex.rs_out' versus '/tmp/org.example.complex.rs'', tests/generator.rs:34:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Let me know if you need some more information.

Error without Box

rust/varlink/src/error.rs

Line 88 in 8e11f3a

self.1.as_ref().map(|e| e.as_ref())

self.1.as_ref().map(|e| e.as_ref());
self.1.as_ref().map(Box::as_ref)

https://play.integer32.com/?version=stable&mode=debug&edition=2018&gist=b5067318e7040aba86c5dcabbcce5c1a

varlink_derive compilation error: proc_macro only usable with crates of the proc-macro crate type

Hi! I'm trying to use varlink_derive and I'm seeing this compilation error in our CI:

Building src/lib.rs (varlink_derive)

Running rustc --crate-name varlink_derive src/lib.rs --crate-type lib -C opt-level=3 -C codegen-units=2 --edition 2018 -C metadata=6ab36ceda7 -C extra-filename=-6ab36ceda7 --out-dir target/lib --emit=dep-info,link -L dependency=target/deps --extern varlink_generator=/nix/store/fx04h2n6q0ipli7hm7zknspgjfi0qiva-rust_varlink_generator-8.0.0/lib/libvarlink_generator-10e2cd43da.rlib --cap-lints allow --color always

error: the `#[proc_macro]` attribute is only usable with crates of the `proc-macro` crate type

  --> src/lib.rs:61:1

   |

61 | #[proc_macro]

   | ^^^^^^^^^^^^^

error: the `#[proc_macro]` attribute is only usable with crates of the `proc-macro` crate type

  --> src/lib.rs:84:1

   |

84 | #[proc_macro]

   | ^^^^^^^^^^^^^

error: aborting due to 2 previous errors

(from https://travis-ci.org/target/lorri/jobs/623110880#L2842-L2856)

I noticed two things:

varlink_derive is indeed a lib:

rust/varlink_derive/Cargo.toml

Line 12 in 8316048

[lib]
varlink_derive has proc_macro = true:

rust/varlink_derive/Cargo.toml

Line 13 in 8316048

proc_macro = true

whereas the Rust docs say that such libraries should set proc-macro = true (note the dash).

I don't get this compilation error in all build environments though - any idea what could be going on here?

Need more documentation when using without `build.rs`

My project already has output struct and error defined somewhere with many traits.
Hence using build.rs seems not a good idea.

I am hoping you could provide documents explains how to code it from scratch.

Thank you.

Does not compile on 32-bit Windows

   Compiling varlink v7.0.0
error[E0308]: mismatched types
   --> C:\Users\appveyor\.cargo\registry\src\github.com-1ecc6299db9ec823\varlink-7.0.0\src\server.rs:227:63
    |
227 |                             Some(TcpListener::from_raw_socket(l as u64)),
    |                                                               ^^^^^^^^ expected u32, found u64
error[E0308]: mismatched types
   --> C:\Users\appveyor\.cargo\registry\src\github.com-1ecc6299db9ec823\varlink-7.0.0\src\server.rs:234:64
    |
234 |                             Some(UnixListener::from_raw_socket(l as u64)),
    |                                                                ^^^^^^^^ expected u32, found u64
error: aborting due to 2 previous errors

Worker thread exhaustion

I'm working on a project that uses varlink (c.f. https://github.com/nyarly/lorri/blob/stream_events/src/daemon/rpc.rs)

It appears that clients connecting to the Monitor interface are leaking worker threads - even after those clients disconnect, the thread remains listening. Previously, we used raw sockets, and the closing of the socket immediately released the thread.

Now I'm seeing sockets left open when the client program exits, and the worker threads hanging out (and trying to send new events to those sockets and hanging.)

Provide async API

Since it's an IPC API, it should be async. Moreover, I think async should be the primary/main API, with blocking wrappers on top.

I understand this is going to be a major change/break but given that currently this crate has not many users, I think that shouldn't be a concern. It'll involve bumping the major number of course.

The real problem (apart from this being a big project), is going to be implementing an async runtime-agnostic solution. The bad news is that there is no good solution for this (for now). The good news is that I've dealt with this problem in zbus and we've a not-so-bad solution now: be runtime agnostic by default using smol-rs crates and providing tight integration with tokio (through an optional feature).

It might be possible to reuse some or all of the abstractions we've in zbus for this.

custom {de,}serialization

AFAICS the generator will always define a native Rust struct and offload the
derivation of Deserialize and Serialize to Serde. Often it would be
convenient if custom serialization could be made to work for Varlink types. The
motivation is mainly to prevent extra copies / conversions when working with
FFI.

IOW currently the path between JSON and opaque FFI type is JSON ←→ Rust struct
←→ FFI struct; ideally it would be just JSON ←→ FFI struct.

Say I have an interface

interface bar.foo
type Foo (
    one: string,
    two: int
)
method GetFoo() -> (foo: Foo)

Varlink will define a struct Foo containing those fields and a trait
Call_GetFoo that handles such a struct. Now I’m actually converting the
struct directly into some opaque FFI type:

#[repr(C)] pub struct FFI_FOO { _private: [u8; 0], }

discarding the Rust struct immediately after.

I’m looking for a way of hooking into the varlink generator so it defines an
alternative to Call_GetFoo that instead uses the newtype FFI_FOO_PTR:

struct FFI_FOO_PTR (*mut FFI_FOO);

which has implementations for Deserialize and Serialize.

Please tag v10.0.0

Hi! According to crates.io, v10.0.0 is the latest published version of varlink. However, v4.0.0 is the latest tag I could find, and it's also the latest release tagged on Github.

It would be great to have tags for later releases to browse the source code of precisely that release. I don't think it's necessary to go through that exercise for old releases, but for 10.0.0, could you please push a tag for exactly the commit that was published to crates.io?

Inability to use `handle` in all server implementations

The comment:

impl ConnectionHandler for VarlinkService {
    /// Handles incoming varlink messages from `reader` and sends the reply on `writer`.
    ///
    /// This method can be used to implement your own server.
    fn handle(&self, bufreader: &mut BufRead, writer: &mut Write) -> Result<()> {

seems to imply that the handle method can be used to implement your own server. However if a user wants to implement a server using a single process and multiplex using poll with non-blocking sockets, then I don't see how this handle function can accommodate it?

[Question] stdin/stdout of varlink service

Can varlink service support listen on stdin? For example:

echo 'info.example.varlink.Get' | ./varlink_service 0

I got error about InvalidAddress as it should be bigger than 2.

The expectation is 1 time run of service on given call.
I noticed varlink bridge support stdin/stdout, but never got a chance
to get it up and running.

Have varlink::generator support i128 integers

The specification states that the int size is implementation specific. Rust supports i128 ref. https://doc.rust-lang.org/std/primitive.i128.html and it would be good for some use cases to allow the code generation to utilize them instead of i64. Having a way to pass this option to cargo_build_source and potentially other future options, would be a useful addition IMHO.

[Question] Overriding Display for Error Types?

I've got a quick question about the varlink generated error types. Take this generated code for example:

pub enum ErrorKind {
    Varlink_Error,
    VarlinkReply_Error,
    Error(Option<Error_Args>),
    HookFailed(Option<HookFailed_Args>),
}

I have two user-defined errors in my .varlink file: Error, and HookFailed. My question is, why are the error arguments inside of an Option? According to the varlink definition, the error must have the arguments that I have defined, so in what cases would the error Arguments be None? I'm mostly trying to figure out if a None value in this case should be a panic, or whether or not that can happen in normal operation.

Updating from varlink 1.1.0 to varlink 7.0.0 auto code generation compile errors

Trying to resurrect the idea of using varlink instead of dbus for a project I'm working on. When I update from varlink 1.1.0 to 7.0.0 I get compiler errors on auto generated code (same error repeated many times):

error[E0277]: the trait bound `varlink_api::org_storage_stratis1::Error: std::convert::From<varlink::ErrorKind>` is not satisfied                                           
   --> src/varlink_api/org_storage_stratis1.rs:385:5                                                                                                                        
    |                                                                                                                                                                       
385 | /     fn block_dev_user_info_set(                                                                                                                                     
386 | |         &mut self,                                                                                                                                                  
387 | |         r#pool_uuid: String,                                                                                                                                        
388 | |         r#block_dev_uuid: String,                                                                                                                                   
389 | |         r#user_info: String,                                                                                                                                        
390 | |     ) -> varlink::MethodCall<BlockDevUserInfoSet_Args, BlockDevUserInfoSet_Reply, Error>;                                                                           
    | |_________________________________________________________________________________________^ the trait `std::convert::From<varlink::ErrorKind>` is not implemented for `varlink_api::org_storage_stratis1::Error`
    |                                                                                                                                                                       
    = help: the following implementations were found:                                                                                                                       
              <varlink_api::org_storage_stratis1::Error as std::convert::From<failure::Context<varlink_api::org_storage_stratis1::ErrorKind>>>                              
              <varlink_api::org_storage_stratis1::Error as std::convert::From<serde_json::Error>>                                                                           
              <varlink_api::org_storage_stratis1::Error as std::convert::From<std::io::Error>>                                                                              
              <varlink_api::org_storage_stratis1::Error as std::convert::From<varlink_api::org_storage_stratis1::ErrorKind>>                                                
            and 2 others                                                                                                                                                    
    = note: required because of the requirements on the impl of `std::convert::Into<varlink_api::org_storage_stratis1::Error>` for `varlink::ErrorKind`                     
    = note: required because of the requirements on the impl of `chainerror::ChainErrorFrom<varlink::ErrorKind>` for `varlink_api::org_storage_stratis1::Error`             
    = note: required by `varlink::MethodCall`

If I specify varlink_generator = "7" instead of varlink_generator = "6" as stated in the docs
https://docs.rs/varlink/7.0.0/varlink/ I get:

error[E0658]: imports can only refer to extern crate names passed with `--extern` on stable channel (see issue #53130)                                                      
  --> /home/tasleson/.cargo/registry/src/github.com-1ecc6299db9ec823/varlink_parser-4.0.0/src/lib.rs:57:9                                                                   
   |                                                                                                                                                                        
55 | mod format;                                                                                                                                                            
   | ----------- not an extern crate passed with `--extern`                                                                                                                 
56 |                                                                                                                                                                        
57 | pub use format::{Format, FormatColored};                                                                                                                               
   |         ^^^^^^                                                                                                                                                         
   |                                                                                                                                                                        
note: this import refers to the module defined here                                                                                                                         
  --> /home/tasleson/.cargo/registry/src/github.com-1ecc6299db9ec823/varlink_parser-4.0.0/src/lib.rs:55:1                                                                   
   |                                                                                                                                                                        
55 | mod format;                                                                                                                                                            
   | ^^^^^^^^^^^                                                                                                                                                            
                                                                                                                                                                            
error: aborting due to previous error                                                                                                                                       
                                                                                                                                                                            
For more information about this error, try `rustc --explain E0658`.                                                                                                         
error: Could not compile `varlink_parser`.

Branch with commits which has 1.1.0 compiling and latest commit to convert over to 7.0.0 failing:
https://github.com/tasleson/stratisd/commits/varlink_ipc

Question on the names of returned variables

This simple client is working for my in progress varlink service. However, the returned variables have r# prefix, eg. r#version, r#pools, why? Earlier version of library did not.

extern crate libstratis;
extern crate varlink;

use libstratis::varlink_api::{VarlinkClient, VarlinkClientInterface};
use varlink::Connection;

fn main() {
    let connection = Connection::with_address("unix:@stratis-storage1").unwrap();
    let mut client = VarlinkClient::new(connection);

    let version = client.version().call().unwrap();
    println!("Daemon version = {}", version.r#version);

    let pools = client.pools().call().unwrap();

    for p in pools.r#pools {
        println!("{:?}", p);
    }
}

RUSTSEC-2021-0139: ansi_term is Unmaintained

ansi_term is Unmaintained

Details
Status	unmaintained
Package	`ansi_term`
Version	`0.12.1`
URL	ogham/rust-ansi-term#72
Date	2021-08-18

The maintainer has adviced this crate is deprecated and will not receive any maintenance.

The crate does not seem to have much dependencies and may or may not be ok to use as-is.

Last release seems to have been three years ago.

Possible Alternative(s)

The below list has not been vetted in any way and may or may not contain alternatives;

See advisory page for additional details.

p.s. use Github actions to get these alerts automagically!

RFE: use nix instead of libc directly?

This way you would not need to do unsafe stuff and casting around.