spec: reconsider SHELL/HOME environment variables

[jonboulle]

As of c8559a2 the environment variables mandated by the spec are as follows:

1. PATH
2. USER
3. LOGNAME (same as USER)
4. HOME
5. SHELL
6. AC_APP_NAME
7. AC_METADATA_URL

1, 2 and 3 seem relatively uncontroversial - it's reasonable to assume every app executing on a modern OS has these concepts (inherently associated with the process). 6 and 7 are similarly straightforward expectations defined clearly in the spec itself.

4 and 5 are slightly more problematic because, although part of the POSIX passwd, their significance and relevance for applications executing in containers is murky. They are conceptually really associated with an interactive user (--> login session), and it seems to me it should be possible to completely implement the execution side of the appc spec without introducing such a notion. Also, these are traditionally looked up from a database like /etc/passwd and it is unclear how this should be discussed (if at all) in the spec. Related: #231

Throwing out a few ideas for clarifying this:

• Declare only that HOME and SHELL should have "sensible" values but do not have any particular significance or requirements in the spec itself
• Remove SHELL entirely from the list of required environment variables (now that we have relaxed the restrictions on what can be set)
• Make SHELL optional and mandate (or recommend?) that it be used iff interactive sessions are to be supported
• Stipulate that HOME must reference a directory in the rootfs that is writeable by the user (i.e. the app.User field)

[vcaputo]

I think the spec should only require PATH, AC_APP_NAME, and AC_METADATA_URL.

After that things get muddy, is the spec going to require a user database @ /etc/passwd where USER/LOGNAME may be looked up? These names have no meaning to the kernel as it works only with numeric identifiers, userspace gives meaning to this stuff, where do we want the line drawn?

Even PATH can be argued as a userspace detail, execvp() is libc, not a kernel interface.

I understand many applications will assume these environment variables are set, but I think this is probably something actool should cater to when building the ACI, not something the ACE should magically make happen.

[eyakubovich]

I agree with @vcaputo. Let's just have the AC_* vars and have the rest be set to reasonable defaults during the authoring process (e.g. via actool). actool can then provide a way to override the defaults. It can also then generate these extra files files like expected by libc: /etc/passwd, /etc/services, etc.

[jonboulle]

@vcaputo yes, you are right, I overlooked the ambiguity of 2 and 3. This is really something we need to clarify with #231 (what significance is there, if any, to the user specified in the image?)

@eyakubovich whoah, that behaviour sounds like a bit of a non sequitur/feature creep. Why should actool be in the business of generating passwd databases and other libc files? At that point we basically need to mandate them in the spec. Unless you are talking about some kind of actool build --with-libc mode or something. And what about other ACI building workflows?

[vcaputo]

@jonboulle it's just that at the end of the day we want users to be successful. That may require the tooling used to build these images to do more hand-holding, especially if the ACE isn't going to be attempting to magically fill the potential gaps.

[eyakubovich]

@jonboulle yeah, definitely with --with-libc. What we want is ACI to be as self sufficient and explicit as possible (it would contain all the needed files and env vars in manifest). But to ease the creation of all these "systemsy" bits, the tooling can help. So actool can add some boilerplate, if asked.

[jonboulle]

I agree with the goals you're both pushing, and that tooling should be able to help with creating fully functional ACIs. But I think it would still behoove us to discuss this in the spec (particularly the parts intimately related to #231) without just completely throwing out all of the vars.

[thockin]

I flagged this issue on my read-through this weekend.

USER, LOGNAME, HOME, and SHELL all imply some standard passwd structure. I don't think you want to make that assumption.

I could MAYBE see these rules:

• Set LOGNAME and USER iff the uid was set to non-numeric, but that's a whole other issue I realized with the spec as it is - it may be unreasonable to actually parse non-numeric uid/gid - nsswitch can be arbitrarily complicated -- are you going to make ACE process nsswitch, talk to LDAP or NIS+, process arbitrary on-disk files, etc? That seems like an attack vector to me.
• Set HOME to $workingDir

[jonboulle]

@thockin @eyakubovich @vcaputo took a swing at this, ptal

[thockin]

Is there some real requirement driving the desire for these? I feel like this is soft enough that it doesn't matter at all and should just be stricken entirely.

[jonboulle]

I was anticipating that there is still a nontrivial amount of software that does depend on these things and so it would be worth gently nudging implementers in that direction. But I don't feel strongly enough about it to keep fighting this :-)

[thockin]

Nothing says an implementation CAN'T do it, I just don't know that this
adds much to the spec.

On Thu, May 7, 2015 at 4:13 PM, Jonathan Boulle notifications@github.com
wrote:

In OS-SPEC.md #273 (comment)
:

@@ -7,12 +7,23 @@ This document attempts to define a minimal set of things that must exist for mos

ACIs that define the label os=linux can expect this environment by default.

+## Execution Environment
+
+It is RECOMMENDED that the following environment variables be set for each application's main process and any lifecycle processes:

I was anticipating that there is still a nontrivial amount of software
that does depend on these things and so it would be worth gently nudging
implementers in that direction. But I don't feel strongly enough about it
to keep fighting this :-)

—
Reply to this email directly or view it on GitHub
https://github.com/appc/spec/pull/273/files#r29905247.

[jonboulle]

updated

[thockin]

beautiful

[jonboulle]

@thockin you need to use more gifs to express yourself IMO

[thockin]

[jonboulle]