public inbox for pbs-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Dietmar Maurer <dietmar@proxmox.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
	Proxmox Backup Server development discussion
	<pbs-devel@lists.proxmox.com>
Subject: Re: [pbs-devel] [PATCH proxmox-backup 1/2] support more ENV vars to get secret values
Date: Wed, 21 Jul 2021 10:47:36 +0200 (CEST)	[thread overview]
Message-ID: <1061967662.248.1626857256576@webmail.proxmox.com> (raw)

> what about newlines in secrets? I can have them in the "direct" use, where we may not
> change that for backward compatibility, but not in the fd/file/command use?
> 
> I can get where this comes from, and while it feels a bit inconsistent it can be OK but must
> be at least documented a bit more explicitly.

In general, passwords should be arbitrary binary data &[u8]. But this is clumsy because we want to
use the password with our REST interface, which requires UTF8 (json). We also read password from the 
console and use newline as input terminator. So it is impossible to read password with newlines from  
the tty.

Sigh...

> > +///
> > +/// Only return the first line when reading from a file or command.
> > +pub fn get_secret_from_env(base_name: &str) -> Result<Option<String>, Error> {
> > +
> > +    match std::env::var(base_name) {
> > +        Ok(p) => return Ok(Some(p)),
> > +        Err(NotUnicode(_)) => bail!(format!("{} contains bad characters", base_name)),
> > +        Err(NotPresent) => {},
> > +    };
> > +
> > +    let firstline = |data: String| -> String {
> > +        match data.lines().next() {
> > +            Some(line) => line.to_string(),
> > +            None => String::new(),
> > +        }
> > +    };
> > +
> > +    let env_name = format!("{}_FD", base_name);
> > +    match std::env::var(&env_name) {
> > +        Ok(fd_str) => {
> > +            let fd: i32 = fd_str.parse()
> > +                .map_err(|err| format_err!("unable to parse file descriptor in ENV({}): {}", env_name, err))?;
> > +            let mut file = unsafe { File::from_raw_fd(fd) };
> > +            let mut buffer = String::new();
> > +            let _ = file.read_to_string(&mut buffer)?;
> 
> 
> Avoiding to read all of the file (which could be rather big in theory)
> wouldn't be that much more code, i.e., above line would become
> 
> let mut reader = BufReader::new(file);
> let _ = reader.read_line(&mut line)?;

Unfortunately, this returns the line including the '\n'. Instead, we need to use
the "std::io::Lines" iterator: reader.lines().next()

> > +            return Ok(Some(firstline(buffer)));
> > +        }
> > +        _ => {}
> > +    }
> > +
> > +    let env_name = format!("{}_FILE", base_name);
> > +    match std::env::var(&env_name) {
> > +        Ok(filename) => {
> > +            let data = proxmox::tools::fs::file_read_string(filename)?;
> 
> why not proxmox::tools::fs::file_read_firstline ?

Because that also includes the newline ... 

> looks OK besides that, and besides a more detailed rust-docs I have no hard feelings for the other things.

Will send a v2 with your suggestions.




             reply	other threads:[~2021-07-21  8:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-21  8:47 Dietmar Maurer [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-07-19  9:21 Dietmar Maurer
2021-07-19 13:40 ` Thomas Lamprecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1061967662.248.1626857256576@webmail.proxmox.com \
    --to=dietmar@proxmox.com \
    --cc=pbs-devel@lists.proxmox.com \
    --cc=t.lamprecht@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal