Add support privilege when create service

[jimmyxian]

Implement: #1030
Signed-off-by: Xian Chaobo xianchaobo@huawei.com

[aaronlehmann]

Field names in protobuf should be lowercase (privileged). They automatically get converted to go-style CamelCase names when the Go code is generated.

[jimmyxian]

@aaronlehmann Thanks for the review. I will modify this now. :)

[jimmyxian]

@aaronlehmann Review again. Thanks

[codecov-io]

Current coverage is 55.09%

Merging #1129 into master will decrease coverage by 0.02%

@@             master      #1129   diff @@
==========================================
  Files            77         77          
  Lines         12079      12080     +1   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
- Hits           6658       6655     -3   
- Misses         4505       4508     +3   
- Partials        916        917     +1   

Powered by Codecov. Last updated by f98068e...e5fa1d9

[jimmyxian]

ping @stevvooe @aluzzardi @aaronlehmann

[stevvooe]

@jimmyxian Adding privileged greatly impacts the security model. Proper considerations need to be made before adding support for this operation.

[dperny]

I think this was a pull request before its time. There will come a day when we add --privileged to swarmkit, but today is not that day.

Closing. Feel free to reopen later on (or right now), if you disagree.

[aluzzardi]

The demand for --privileged is pretty strong actually. @mgoelzer: thoughts?

[stevvooe]

@aluzzardi What about the profile proposal?

[diogomonica]

I strongly urge us not to take the easy way out on this one. This will haunt us forever.

If the demand is strong, I suggest we prioritize coming up with decent profiles, or at least an early extensible version that fits the use-case.

[ghost]

I think we should add --privileged. My concern with finer grained solutions is that, although I agree they are more elegant, it will take a long time to come to agreement on how one should work. What do users do during that period of time?

[stevvooe]

@mgoelzer There are no required changes for the profile model. The profile mode hardwires --privileged to a particular profile. The initial proposal only has default and privileged.

[aluzzardi]

What I don't like about profiles is that now "privileged" is just a string. The behavior becomes not portable.

[tiny1990]

@jimmyxian not merge?

[kent-h]

Have any steps been made towards this? What about the related --cap-add, --cap-drop, --pid=host, & --security-opt? (Listing off the requirements for my current use case.)

Personally, I believe this should have been merged. Mirroring the current docker run capabilities is likely more helpful for end-users than waiting for a security model rewrite (which does not seem to have a timeline).

I tend to view swarm as nothing more than a control layer for docker. Given this, my suggestion is that swarm mode should mirror as much of the docker functionality as possible (i.e. - just store and pass on every docker run parameter, unless there's no direct mapping to swarm mode (--rm, etc.)

My opinion is obviously biased. Could we get this re-opened for discussion?

[lipingxue]

Is there any progress on this to support --privileged option?

[codeskyblue]

ping