Running without HOME gives multiple errors even when overriding region/credentials providers

[joshtriplett]

Describe the bug

I'm running in a small locked-down environment with very few variables set; in particular, I'm running without an existent HOME directory. I've configured the client to use non-default providers for credentials and region. However, when initializing, the client still emits half a dozen warning messages via tracing about not finding a home directory, from src/profile/parser/source.rs within aws-config. I'm not running on Lambda, but I'm in the same category where this warning isn't helpful.

I'd like to be able to easily disable all attempts to access HOME. (Ideally, I don't just want to suppress the warning; I'd like to suppress the actual attempts, and associated initialization time.)

Expected Behavior

Some means of suppressing the attempts to access HOME.

Current Behavior

Half a dozen warnings through tracing saying could not determine home directory but home expansion was requested, from src/profile/parser/source.rs within aws-config.

Reproduction Steps

src/main.rs:

use anyhow::anyhow;
use tracing::{info_span, Instrument};
use tracing_subscriber::filter::LevelFilter;
use tracing_subscriber::prelude::*;

const INSTANCE_METADATA_HOST: &str = "http://169.254.169.254";

#[async_std::main]
async fn main() -> anyhow::Result<()> {
    let stderr_layer = tracing_subscriber::fmt::layer()
        .with_target(false)
        .with_writer(std::io::stderr);
    tracing_subscriber::Registry::default()
        .with(stderr_layer)
        .with(LevelFilter::from(tracing::Level::INFO))
        .init();

    let https_connector = hyper_rustls::HttpsConnectorBuilder::new()
        .with_webpki_roots()
        .https_or_http()
        .enable_http1()
        .enable_http2()
        .build();
    let adapter = aws_smithy_client::hyper_ext::Adapter::builder().build(https_connector);
    let dyn_connector = aws_smithy_client::erase::DynConnector::new(adapter.clone());
    let region = aws_sdk_sts::Region::new("us-west-2");
    let provider_config = aws_config::provider_config::ProviderConfig::without_region()
        .with_region(Some(region.clone()))
        .with_http_connector(dyn_connector.clone());
    let imds_client = aws_config::imds::Client::builder()
        .configure(&provider_config)
        .endpoint(http::Uri::from_static(INSTANCE_METADATA_HOST))
        .build()
        .await?;
    let credentials_provider = aws_config::imds::credentials::ImdsCredentialsProvider::builder()
        .imds_client(imds_client)
        .configure(&provider_config)
        .build();
    let credentials_provider =
        aws_config::meta::credentials::LazyCachingCredentialsProvider::builder()
            .configure(&provider_config)
            .load(credentials_provider)
            .build();
    let aws_sdk_config = aws_config::from_env()
        .http_connector(aws_smithy_client::http_connector::HttpConnector::Prebuilt(
            Some(dyn_connector),
        ))
        .configure(provider_config)
        .region(region)
        .credentials_provider(credentials_provider)
        .load()
        .await;

    let sts = aws_sdk_sts::Client::from_conf_conn(From::from(&aws_sdk_config), adapter.clone());

    // Get the AWS account ID.
    let caller_identity = sts
        .get_caller_identity()
        .send()
        .instrument(info_span!("GetCallerIdentity"))
        .await?;
    let aws_account_id = caller_identity
        .account
        .ok_or_else(|| anyhow!("Could not get AWS account ID"))?;

    dbg!(aws_account_id);

    Ok(())
}

Cargo.toml:

[package]
name = "foo"
version = "0.1.0"
edition = "2021"

[dependencies]
anyhow = "1.0.58"
async-std = { version = "1.12.0", features = ["attributes", "tokio1"] }
aws-config = { version = "0.15.0", default-features = false, features = ["rustls"] } # rustls feature required to work around compilation error
aws-sdk-sts = { version = "0.15.0", default-features = false }
aws-smithy-client = "0.45.0"
http = "0.2.8"
hyper-rustls = { version = "0.23.0", default-features = false, features = ["http1", "http2", "tls12", "webpki-roots", "webpki-tokio"] }
tracing = { version = "0.1.29", features = ["max_level_info", "release_max_level_info"] }
tracing-subscriber = { version = "0.3.11", default-features = false, features = ["fmt"] }

Possible Solution

No response

Additional Information/Context

For reproducing this, it may help to build with --target x86_64-unknown-linux-musl, and put the resulting binary into a chroot, with just an /etc/resolv.conf and nothing else. Run it with chroot and an unset HOME.

Version

├── aws-config v0.15.0
│   ├── aws-http v0.15.0
│   │   ├── aws-smithy-http v0.45.0
│   │   │   ├── aws-smithy-types v0.45.0
│   │   ├── aws-smithy-types v0.45.0 (*)
│   │   ├── aws-types v0.15.0
│   │   │   ├── aws-smithy-async v0.45.0
│   │   │   ├── aws-smithy-client v0.45.0
│   │   │   │   ├── aws-smithy-async v0.45.0 (*)
│   │   │   │   ├── aws-smithy-http v0.45.0 (*)
│   │   │   │   ├── aws-smithy-http-tower v0.45.0
│   │   │   │   │   ├── aws-smithy-http v0.45.0 (*)
│   │   │   │   ├── aws-smithy-types v0.45.0 (*)
│   │   │   ├── aws-smithy-http v0.45.0 (*)
│   │   │   ├── aws-smithy-types v0.45.0 (*)
│   ├── aws-sdk-sso v0.15.0
│   │   ├── aws-endpoint v0.15.0
│   │   │   ├── aws-smithy-http v0.45.0 (*)
│   │   │   ├── aws-types v0.15.0 (*)
│   │   ├── aws-http v0.15.0 (*)
│   │   ├── aws-sig-auth v0.15.0
│   │   │   ├── aws-sigv4 v0.15.0
│   │   │   │   ├── aws-smithy-http v0.45.0 (*)
│   │   │   ├── aws-smithy-http v0.45.0 (*)
│   │   │   ├── aws-types v0.15.0 (*)
│   │   ├── aws-smithy-async v0.45.0 (*)
│   │   ├── aws-smithy-client v0.45.0 (*)
│   │   ├── aws-smithy-http v0.45.0 (*)
│   │   ├── aws-smithy-http-tower v0.45.0 (*)
│   │   ├── aws-smithy-json v0.45.0
│   │   │   └── aws-smithy-types v0.45.0 (*)
│   │   ├── aws-smithy-types v0.45.0 (*)
│   │   ├── aws-types v0.15.0 (*)
│   ├── aws-sdk-sts v0.15.0
│   │   ├── aws-endpoint v0.15.0 (*)
│   │   ├── aws-http v0.15.0 (*)
│   │   ├── aws-sig-auth v0.15.0 (*)
│   │   ├── aws-smithy-async v0.45.0 (*)
│   │   ├── aws-smithy-client v0.45.0 (*)
│   │   ├── aws-smithy-http v0.45.0 (*)
│   │   ├── aws-smithy-http-tower v0.45.0 (*)
│   │   ├── aws-smithy-query v0.45.0
│   │   │   ├── aws-smithy-types v0.45.0 (*)
│   │   ├── aws-smithy-types v0.45.0 (*)
│   │   ├── aws-smithy-xml v0.45.0
│   │   ├── aws-types v0.15.0 (*)
│   ├── aws-smithy-async v0.45.0 (*)
│   ├── aws-smithy-client v0.45.0 (*)
│   ├── aws-smithy-http v0.45.0 (*)
│   ├── aws-smithy-http-tower v0.45.0 (*)
│   ├── aws-smithy-json v0.45.0 (*)
│   ├── aws-smithy-types v0.45.0 (*)
│   ├── aws-types v0.15.0 (*)
├── aws-sdk-sts v0.15.0 (*)
├── aws-smithy-client v0.45.0 (*)

Environment details (OS name and version, etc.)

Debian, latest sid

Logs

No response

[Velfi]

The reason the warnings are displayed so often is because we parse the profile multiple times when building the shared config.

To whomever ends up taking on this task, here's what should be done:

• Whenever we need to access the home directory, check if the $HOME environment variable exists.
  • If it doesn't exist, then don't emit a warning
  • If it does exist but it's invalid, emit a warning

[jdisanti]

After digging into this a bit, I realized our original assessment on next steps wouldn't improve the situation. I took a different approach of only emitting the warning if the profile path was explicitly overridden in smithy-lang/smithy-rs#1558.

[jdisanti]

This went out in the July 21st SDK release.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.