Comments (8)
On Tue, Jun 30, 2015 at 04:14:17PM -0700, Brandon Philips wrote:
Right now the spec says you need to specify an OS relevant user id
for the process to exec on behalf of. Many people don't think about
this low-level primitive and rely on user databases like
/etc/passwd
. In order to support a user sayingapache
in the
open container configuration…
I don't think we need to do this. Using UID/GID is easy for the
runtime 1, and ‘id -u apache’, etc., is easy for bundle authors.
from runtime-spec.
On Sun, Sep 06, 2015 at 02:01:42PM -0700, W. Trevor King wrote:
I don't think we need to do this. Using UID/GID is easy for the
runtime [1], and ‘id -u apache’, etc., is easy for bundle authors.
Of course, they'd have to enter the bundle for that ‘id’ call to work
;). So maybe not super-trivial, but I still think we should be
offloading the UID/GID lookup to bundle-author tooling.
from runtime-spec.
bumping this since we're getting past the first milestone and starting to talk about usability now. I can't think of a good way to implement a pretty common use case like docker run -u myuser /bin/bash
without mapping usernames to uids. I think this becomes particularly important where you're trying to support 'runc exec' or having multiple bundles that share a namespace. If you consider a case where the second bundle wants to log in as a user added/modified by the first bundle, it doesn't make sense to try to create the bundle with a pre-mapped uid: the user literally may not exist (or may exist with the wrong uid) when the bundle is created. The only sane way I can think of to handle this is for the runtime to do the mapping before executing the second bundle.
User is already a platform-specific structure so I'm struggling to think of great arguments to not allow specifying a username that the runtime will map to a uid. Does anyone actually feel strongly about the runtime not mapping username->uid once the first draft is done?
from runtime-spec.
Coming back to the original issue, parsing /etc/passwd seems better to me because I don't think we can rely on getent existing in the rootfs (I can imagine cut-down rootfses that don't have it). The appc spec wording seems pretty great here imho.
from runtime-spec.
On Tue, Sep 15, 2015 at 01:49:14PM -0700, Julian Friedman wrote:
Coming back to the original issue, parsing /etc/passwd seems better
to me because I don't think we can rely on getent existing in the
rootfs…
We might not have the entry in /etc/passwd though (maybe the bundle
intends to use NIS or LDAP to lookup the user you're asking for).
On the other hand, all my bundles will have users in /etc/passwd, so
I'm ok going with “just parse /etc/passwd” until we hear complaints
from folks using alternative systems.
The appc spec wording seems pretty great here imho.
That looks good to me too, although strangely they require numeric IDs
for supplementaryGids. I think we should use whatever logic we decide
on for both the user, group, and additionalGids.
from runtime-spec.
Is this really required for the spec? uid
is sufficient, and if username
can not be resolved, then it's undefined behavior.
from runtime-spec.
On Wed, Mar 16, 2016 at 10:49:27AM -0700, Vincent Batts wrote:
Is this really required for the spec?
@crosbymichael closed #191 as out-of-scope for the runtime 1, which
sounds fine to me 2.
from runtime-spec.
Closing this. I agree with the assessment in #191
from runtime-spec.
Related Issues (20)
- runtime.md: State MUST be serialized with specific indentation pattern? HOT 3
- `runAsGroup` vs `supplementalGroups` HOT 3
- support PostExit Hook HOT 11
- Proposal: Add the `update` operation HOT 1
- When using Windows containers in Containerd the windows layerFolder is null and the root is blank HOT 10
- whether update container delete doc
- When running `make rust-oci-tests` getting error `container state could not be retrieved successfully.` HOT 3
- features.md: add unsafe annotation list HOT 2
- config-linux: Should we clarify when should we set the swap limit? HOT 2
- idmapped mounts: should they be applied recursively?
- dev versions don't respect semver HOT 6
- features: mountExtensions: how best to represent feature support for idmap? HOT 5
- Update `config_linux.md` when libseccomp `v2.6.0` is relased
- Why does the oci runtime spec define the runtime operation after the proposal of" runtime CLI spec" has been rejected? HOT 2
- Proposal: Support filter (Includes and Excludes) feature in LinuxSyscall HOT 7
- Proposal: Network Devices HOT 12
- Build error with clang++ 17 HOT 7
- Proposal: use pre-generated BPF filter HOT 3
- Damarcus Jones Professional
- Proposal: synchronize cgroupv1 deprecation announcements HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from runtime-spec.