ডকার এবং --userns- রিম্যাপ, হোস্ট এবং ধারকগুলির মধ্যে ডেটা ভাগ করার জন্য ভলিউম অনুমতিগুলি কীভাবে পরিচালনা করবেন?


96

ডকারে, ধারকগুলির ভিতরে তৈরি ফাইলগুলির হোস্টের কাছ থেকে পরিদর্শন করার সময় অপ্রত্যাশিত মালিকানা থাকে। একটি ভলিউমের ফাইলগুলির মালিক ডিফল্টরূপে রুট (uid 0) হয় তবে নন-রুট ব্যবহারকারী অ্যাকাউন্টগুলি পাত্রে জড়িত থাকে এবং ফাইল সিস্টেমে লেখার সাথে সাথে মালিকরা হোস্ট দৃষ্টিকোণ থেকে কম-বেশি এলোমেলো হয়ে যায়।

আপনি যখন একই ব্যবহারকারীর অ্যাকাউন্টটি ডকার কমান্ডগুলি কল করে হোস্টের কাছ থেকে ভলিউম ডেটা অ্যাক্সেস করতে চান তখন এটি একটি সমস্যা।

টিপিক্যাল ওয়ার্কারআউন্ডস হয়

  • ডকফায়াইলগুলিতে তৈরির সময় ব্যবহারকারীদের ইউআইডি জোর করে (পোর্টেবল নয়)
  • docker runপরিবেশের পরিবর্তনশীল হিসাবে কমান্ডটিতে হোস্ট ব্যবহারকারীর ইউআইডি পাস করার পরে chownএকটি এন্টিপয়েন্ট স্ক্রিপ্টে ভলিউমের উপর কিছু কমান্ড চালানো ।

এই উভয় সমাধানই ধারকটির বাইরের প্রকৃত অনুমতিগুলিতে কিছুটা নিয়ন্ত্রণ দিতে পারে।

আমি আশা করলাম ব্যবহারকারীর নামস্পেসগুলি এই সমস্যার চূড়ান্ত সমাধান হবে। আমি সম্প্রতি প্রকাশিত সংস্করণ 1.10 এবং - ডেস্কটপ অ্যাকাউন্টে ইউজারেন্স-রিম্যাপ সেট দিয়ে কিছু পরীক্ষা চালিয়েছি। তবে, আমি নিশ্চিত নই যে এটি মাউন্ট ভলিউমে ফাইল মালিকানা মোকাবেলা করতে আরও সহজ করে তুলতে পারে, আমি ভয় করি যে এটি আসলে বিপরীত হতে পারে।

ধরুন আমি এই বেসিক পাত্রে শুরু করি

docker run -ti -v /data debian:jessie /bin/bash
echo 'hello' > /data/test.txt
exit

এবং তারপরে হোস্টের সামগ্রীটি পরিদর্শন করুন:

ls -lh /var/lib/docker/100000.100000/volumes/<some-id>/_data/

-rw-r--r-- 1 100000 100000 6 Feb  8 19:43 test.txt

এই সংখ্যাটি '100000' আমার হোস্ট ব্যবহারকারীর একটি সাব-ইউআইডি, তবে এটি যেহেতু এটি আমার ব্যবহারকারীর ইউআইডির সাথে সামঞ্জস্য নয়, তবুও আমি বিনা অধিকার ছাড়াই টেস্ট.টেক্সট সম্পাদনা করতে পারি না। এই উপ-ব্যবহারকারীর ডকারের বাইরে আমার প্রকৃত নিয়মিত ব্যবহারকারীর সাথে কোনও সখ্যতা বলে মনে হচ্ছে না। এটি ম্যাপ করা হয়নি।

হোস্ট এবং ধারকটির মধ্যে ইউআইডি প্রান্তিককরণের সমন্বয়ে গঠিত এই পোস্টে এর আগে উল্লিখিত ওয়ার্কআরউন্ডস UID->sub-UIDনেমস্পেসে ম্যাপিংয়ের কারণে আর কাজ করে না ।

তারপরে, হোস্ট ব্যবহারকারীকে ডকারের সাথে চালিত ভলিউমগুলিতে উত্পন্ন ফাইলগুলির মালিকানা তৈরি করার সময়েও ব্যবহারকারী নামস্থান সক্ষম (উন্নত সুরক্ষার জন্য) দিয়ে ডকার চালানোর কোনও উপায় আছে কি?


আমি মনে করি যে আপনি যদি হোস্ট এবং ধারকটির মধ্যে ভলিউম ভাগ করে যাচ্ছেন যে ব্যবহারকারী নামস্থানগুলি সমাধানের অংশ হতে পারে না । আপনার দ্বিতীয় বিকল্প ("হোস্ট ব্যবহারকারীর ইউআইডি পাস করে পরিবেশের পরিবর্তনশীল হিসাবে ডকার রান কমান্ডের কাছে প্রেরণ এবং তারপরে একটি এন্ট্রিপয়েন্ট স্ক্রিপ্টে ভলিউমগুলিতে কিছু ছাঁটা কমান্ড চালানো") সম্ভবত সেরা সমাধান।
লারস্ক

4
ডকার নিজেই হোস্ট-মাউন্টযুক্ত লিখনযোগ্য ভলিউমগুলি ব্যবহার করে উত্সাহিত করে বলে মনে হয় না। যেহেতু আমি কোনও ক্লাউড পরিষেবা চালাচ্ছি না এবং কেবল নিজের বিশ্বাসযোগ্য চিত্রগুলি ব্যবহার করছি, তাই আমি এখন ভাবছি যে এনএসের সুরক্ষা সুবিধাটি এত সুবিধার্থে ত্যাগ করার যোগ্য কিনা?
স্টাফেন সি

@ স্টাফেনসি। আপনি সম্ভবত একটি ভাল পদ্ধতির খুঁজে পেয়েছেন?
আশি আটটি

4
দুর্ভাগ্যক্রমে না, ব্যবহারকারীর নেমস্পেস ব্যবহার না করা এবং হোস্ট থেকে ইউআইডি পাস করা এখনও আমার পছন্দের বিকল্প। আমি আশা করি ভবিষ্যতে ব্যবহারকারীদের মানচিত্রের উপযুক্ত উপায় থাকবে। আমি সন্দেহ করি কিন্তু তবুও, আমি চোখ খোলা রাখি।
স্টাফেন সি

উত্তর:


46

আপনি যদি ব্যবহারকারী এবং গোষ্ঠীগুলি আগে থেকেই সাজিয়ে রাখতে পারেন, তবে ইউআইডি এবং জিআইডিগুলি নির্দিষ্টভাবে নির্দিষ্ট করা সম্ভব যাতে হোস্ট ব্যবহারকারীরা পাত্রে থাকা নেমস্পিড ব্যবহারকারীদের সাথে মিল রাখে।

এখানে একটি উদাহরণ রয়েছে (উবুন্টু 14.04, ডকার 1.10):

  1. নির্দিষ্ট সংখ্যক আইডি সহ কিছু ব্যবহারকারী তৈরি করুন:

    useradd -u 5000 ns1
    
    groupadd -g 500000 ns1-root
    groupadd -g 501000 ns1-user1
    
    useradd -u 500000 -g ns1-root ns1-root
    useradd -u 501000 -g ns1-user1 ns1-user1 -m
    
  2. ম্যানুয়ালি স্বয়ংক্রিয়ভাবে উত্পাদিত অধস্তন আইডি রেঞ্জগুলি /etc/subuidএবং /etc/subgidফাইলগুলি সম্পাদনা করুন:

    ns1:500000:65536
    

    (নোট করুন ns1-rootএবং এর ns1-user1কারণে MAX_UIDএবং এর MAX_GIDসীমাবদ্ধতার জন্য কোনও রেকর্ড নেই /etc/login.defs)

  3. এতে ব্যবহারকারীর নেমস্পেসগুলি সক্ষম করুন /etc/default/docker:

    DOCKER_OPTS="--userns-remap=ns1"
    

    ডেমন পুনরায় চালু করুন service docker restart, /var/lib/docker/500000.500000ডিরেক্টরি তৈরি হয়েছে তা নিশ্চিত করুন ।

    এখন, ভিতরে পাত্রে আপনার আছে rootএবং user1, এবং হোস্ট অন - ns1-rootএবং ns1-user1, ম্যাচিং ID- র সঙ্গে

    আপডেট: গ্যারান্টিযুক্ত যে নন-রুট ব্যবহারকারীরা কনটেইনারগুলিতে নির্দিষ্ট আইডি রয়েছে (উদাহরণস্বরূপ ব্যবহারকারীর 1000: 1000), চিত্র তৈরির সময় তাদের স্পষ্টভাবে তৈরি করুন।

পরীক্ষামূলক চালনা:

  1. একটি ভলিউম ডিরেক্টরি প্রস্তুত করুন

    mkdir /vol1
    chown ns1-root:ns1-root /vol1
    
  2. এটি একটি ধারক থেকে চেষ্টা করুন

    docker run --rm -ti -v /vol1:/vol1 busybox sh
    echo "Hello from container" > /vol1/file
    exit
    
  3. হোস্ট থেকে চেষ্টা করুন

    passwd ns1-root
    login ns1-root
    cat /vol1/file
    echo "can write" >> /vol1/file
    

পোর্টেবল নয় এবং হ্যাকের মতো দেখাচ্ছে তবে এটি কাজ করে।


4
অত্যন্ত আকর্ষণীয় এবং একটি +1 প্রাপ্য। তবে আপনাকে এখনও নিশ্চিত করতে হবে যে আপনার চিত্রের ব্যবহারকারী 1 ইউআইডি 1000 নির্ধারিত হয়েছে Otherwise বিটিডব্লু আমরা কী নিশ্চিত যে সূত্রটি সর্বদা subUID lower bound + UID in imageযদি আমরা ব্যবহারকারীর সাথে আইডিতে 1000 সেট করে রেখে বিভিন্ন চিত্র চালিয়ে যাই?
স্টাফেন সি।

@ স্টাফেনসি। ভাল যুক্তি! চিত্রগুলির অভ্যন্তরে আইডি ফিক্সিং সম্পর্কে একটি নোট যুক্ত করা হয়েছে। সূত্র হিসাবে, আমি আমার নিজের ছবিগুলি নিয়ে আরও পরীক্ষা করতে যাচ্ছি এবং কিছু খুঁজে
পেলে

4
আপনি যদি হোস্ট এবং পাত্রে হাত দ্বারা ব্যবহারকারী এবং গোষ্ঠীগুলি সাজান, আপনার কি সত্যিই "ব্যবহারকারীর নাম স্থান" বৈশিষ্ট্যটি প্রয়োজন?
ত্রিস্তান

4
আপনি যে নেমস্পেসটি তৈরি করেছেন সেটি হোস্ট ব্যবহারকারীদের কনটেইনার ব্যবহারকারীদের থেকে পৃথক করে, তবে আপনার পাত্রে জন্য একাধিক নেমস্পেসের প্রয়োজন হতে পারে, বিশেষত যখন সরকারী চিত্রগুলি (মাইএসকিএল এর মত) স্পষ্টভাবে ইউআইডি ছাড়াই কোনও ব্যবহারকারী তৈরি করে। --Userns-remap বিকল্পটি কেবল একটির প্রত্যাশায় আপনি একাধিক নেমস্পেসের সাথে কীভাবে ব্যবহার করবেন?
ত্রিস্তান

4
@amartynov আমি জিজ্ঞাসা করতে পারি যে আপনি আপনার "এনএস 1" ব্যবহারকারীর জন্য ইউআইডি (5000) নির্দিষ্ট করতে সমস্যা কেন নিয়েছেন? যেহেতু এটি নাম (ইউআইডি নয়) যা আপনি সাবউইড এবং সাবজিড ফাইলগুলিতে উল্লেখ করেছেন তাই মনে হয় এই ব্যবহারকারীটি ইউআইডি কী পায় তা বিবেচ্য নয়। 5000 এবং 500000 এর মধ্যে সাদৃশ্যটি প্রস্তাব করতে পারে বলে আমি কি কিছুটা মিস করছি?
Jollymorphic

2

হোস্টের সাথে ম্যাচ করার জন্য বিল্ড টাইমটিতে গতিশীলভাবে ব্যবহারকারীর ইউআইডি নিযুক্ত করা একটি কাজ ound

উদাহরণ Dockerfile:

FROM ubuntu
# Defines argument which can be passed during build time.
ARG UID=1000
# Create a user with given UID.
RUN useradd -d /home/ubuntu -ms /bin/bash -g root -G sudo -u $UID ubuntu
# Switch to ubuntu user by default.
USER ubuntu
# Check the current uid of the user.
RUN id
# ...

তারপরে এটি তৈরি করুন:

docker build --build-arg UID=$UID -t mycontainer .

এবং হিসাবে চালান:

docker run mycontainer

যদি আপনার বিদ্যমান ধারক থাকে তবে নিম্নলিখিতগুলি সহ একটি মোড়ক ধারক তৈরি করুন Dockerfile:

FROM someexistingcontainer
ARG UID=1000
USER root
# This assumes you've the existing user ubuntu.
RUN usermod -u $UID ubuntu
USER ubuntu

এটি এর docker-compose.ymlমতো মোড়ানো যায় :

version: '3.4'
services:
  myservice:
    command: id
    image: myservice
    build:
      context: .
    volumes:
    - /data:/data:rw

তারপরে এটি তৈরি করুন এবং চালনা করুন:

docker-compose build --build-arg UID=$UID myservice; docker-compose run myservice

4
আমি নিখরচায় দেখতে চাই না তবে এটি আসলে মূল প্রশ্নের তালিকায় থাকা ওয়ার্কআরউন্ডগুলির মধ্যে একটি, তবে কোনও সমাধান নয় এবং ব্যবহারকারীর নামের জায়গার সাথে সম্পর্কিত নয়।
স্টাফেন সি।

@ স্টাফেনসি। আপনি কি এই সম্পর্কিত প্রশ্নে মন্তব্য করতে পারেন? stackoverflow.com/questions/60274418/...
overexchange

-1

docker cpকমান্ডটি ব্যবহার করে আপনি অনুমতি সমস্যাগুলি এড়াতে পারবেন ।

মালিকানা গন্তব্যে ব্যবহারকারী এবং প্রাথমিক গোষ্ঠীতে সেট করা আছে। উদাহরণস্বরূপ, একটি ধারকটিতে অনুলিপি করা ফাইলগুলি UID:GIDরুট ব্যবহারকারী দ্বারা তৈরি করা হয় । স্থানীয় মেশিনে অনুলিপি করা ফাইলগুলি UID:GIDব্যবহারকারীর দ্বারা তৈরি করা হয়েছিল যা docker cpকমান্ডটি প্রেরণ করে।

এখানে আপনার উদাহরণটি ব্যবহারে পরিবর্তন করা হয়েছে docker cp:

$ docker run -ti -v /data debian:jessie /bin/bash
root@e33bb735a70f:/# echo 'hello' > /data/test.txt
root@e33bb735a70f:/# exit
exit
$ docker volume ls
DRIVER              VOLUME NAME
local               f073d0e001fb8a95ad8d919a5680e72b21a457f62a40d671b63c62ae0827bf93
$ sudo ls -l /var/lib/docker/100000.100000/volumes/f073d0e001fb8a95ad8d919a5680e72b21a457f62a40d671b63c62ae0827bf93/_data
total 4
-rw-r--r-- 1 100000 100000 6 Oct  6 10:34 test.txt
$ docker ps -a
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS                          PORTS               NAMES
e33bb735a70f        debian:jessie       "/bin/bash"         About a minute ago   Exited (0) About a minute ago                       determined_hypatia
$ docker cp determined_hypatia:/data/test.txt .
$ ls -l test.txt 
-rw-r--r-- 1 don don 6 Oct  6 10:34 test.txt
$ cat test.txt
hello
$ 

তবে, আপনি যদি কেবল একটি ধারক থেকে ফাইলগুলি পড়তে চান তবে আপনার নামযুক্ত ভলিউমের প্রয়োজন হবে না। এই উদাহরণটিতে নামযুক্ত ভলিউমের পরিবর্তে একটি নামযুক্ত ধারক ব্যবহার করা হয়েছে:

$ docker run -ti --name sandbox1 debian:jessie /bin/bash
root@93d098233cf3:/# echo 'howdy' > /tmp/test.txt
root@93d098233cf3:/# exit
exit
$ docker cp sandbox1:/tmp/test.txt .
$ ls -l test.txt
-rw-r--r-- 1 don don 6 Oct  6 10:52 test.txt
$ cat test.txt
howdy
$ 

এই প্রশ্নে বর্ণিত হিসাবে আমি যখন ধারকগুলিতে ফাইলগুলি অনুলিপি করতে চাই তখন নামযুক্ত ভলিউমগুলি দরকারী বলে মনে করি ।


তবে docker cpডুপ্লিকেট করা ডেটা জড়িত। অধিকন্তু, ডক অনুসারে, কোনও ধারকটিতে ডেটা অনুলিপি করার সময় এটি রুট ব্যবহারকারী অনুসারে মালিকানা আইডি সেট করে, যা প্রায়শই ধারকযুক্ত অ্যাপ্লিকেশনটি চালিত অ্যাকাউন্ট নয়। এটি কীভাবে আমাদের সমস্যার সমাধান করে তা দেখতে আমি ব্যর্থ।
স্টাফেন সি

আপনি ঠিক বলেছেন, @ স্টাফেন, এটিতে নকল তথ্য জড়িত invol তবে ফাইলগুলির অনুলিপিগুলি আপনাকে হোস্ট এবং ধারকটিতে পৃথক মালিকানা এবং অনুমতি নির্ধারণ করতে দেয়। docker cpআপনি যখন কোনও ধারক বা তার ধারক থেকে বাইরে কোনও সংরক্ষণাগার প্রবাহিত করেন তখন আপনাকে ফাইলের মালিকানার উপর সম্পূর্ণ নিয়ন্ত্রণ দেয়। স্ট্রিম করার সাথে সাথে আপনি ট্যারি ফাইলটিতে প্রতিটি প্রবেশের মালিকানা এবং অনুমতিগুলি সামঞ্জস্য করতে পারেন, তাই আপনি রুট ব্যবহারকারীর মধ্যে সীমাবদ্ধ নন।
ডন কার্কবি
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.