I would like to hear Amazon answer the same question under oath.

https://aws.eu/

It looks like FILE is not opaque in glibc. Create a translation unit that includes <stdio.h> & declares a FILE variable and it compiles fine. For comparison, create a translation unit that declares your own struct (but does not provide a definition) and declares a variable of the same type, and you'll get a "storage size of 'x' isn't known" error when compiling.

Thanks for the explanation. In case FILE was opaque in glibc, would the same test (including <stdio.h> and declaring a variable of type FILE) also fail with the unknown storage size error? If so, would linking again some library (-l) be necessary?

EDIT: after some more thinking I assume the key is that we wouldn't be able to have a variable of type FILE, but a pointer, whose size is always known.

You'd have an error about an incomplete type - see https://godbolt.org/z/G4Gsfn7MT

> a pointer, whose size is always known

Yeah, this is exactly how it works. You work with a pointer that acts like a void* in your code, and the library with the definition is allowed to reach into the fields of that pointer. Normally you'd have a C API like

    struct Op;
    Op* init_op();
    void free_op( Op* );
    void do_something_with_op( Op* );

in the header provided by the library that you compile as part of your code, and the definition/implementation in some .a or .so/.dll that you'll link against.*

If I received an email like that I'd reply with an invoice.

Does O_EXCL work with linux USB devices?

> For some reason, instead of only applying its contents to the user environment for the child process like any sane person would do, they are trusting its values for the library calls in the privileged parent itself.

The only safe way to use pam_env's `user_readenv` parameter is as the final rule of `type=session`. This behaves as you'd expect, affecting the child process only.

It appears that openSUSE enables the option for other rule types (auth and/or account), in which case it affects the parent process as well. Oops!

For the record, user_readenv has been disabled since:

    commit 4c430f6f8391555bb1b7b78991afb20d35228efc
    Author: Tomas Mraz <tm@t8m.info>
    Date:   Mon Oct 11 14:24:30 2010 +0000
    
        Relevant BUGIDs:
        
        Purpose of commit: bugfix
        
        Commit summary:
        ---------------
        2010-10-11  Tomas Mraz  <t8m@centrum.cz>
        
                * modules/pam_env/pam_env.c: Change default for user_readenv to 0.
                * modules/pam_env/pam_env.8.xml: Document the new default for user_readenv.

... PAM 1.1.3. And it's been deprecated for a while, to be removed in a future release entirely.

Well put, but it's a shame this comment is the first thing I read, rather than comments about the tool itself!

Any packages with "Essential: yes" (run 'apt list ~E' to see them) are required on any Debian system. Additionally, the 'build-essential' pulls in other packages that must be present to build Debian packages via its dependencies: https://packages.debian.org/sid/build-essential

That's a great site. Finally I think I understand WTF Lenovo mean by "IPMI over Keyboard Controller Style (KCS) Access"

The next version of CVSS needs to add a metric for these kind of bullshit non-vulnerabilities so that we can ignore them at source.