VPN કનેક્શન પછીની ક્રિયા ડેમન તરીકે નહીં, વપરાશકર્તા તરીકે ચલાવો

VPN ડેમન પરના કનેક્શન હૂક ડેમન તરીકે ચાલે છે, અને સામાન્ય રીતે તેનો અર્થ એ છે કે તે root તરીકે ચાલે છે. તે હૂકમાંથી એક જે ક્ષણે કોઈની હોમ ડિરેક્ટરીમાં લખે છે અથવા ડેસ્કટોપ સહાયકને ફરી શરૂ કરે છે, તે ક્ષણે તમે નેટવર્ક ઘટનાને કોઈપણ સ્થાનિક વપરાશકર્તા તરીકે કાર્ય કરવાની ક્ષમતા આપી છે. સામાન્ય ટૂંકો રસ્તો, એટલે કે પર્યાવરણ ચલમાંથી વપરાશકર્તાનું નામ વાંચીને તેને આગળ મોકલવો, તે સુધારતો નથી. તે ક્રિયાને ફરી લેબલ આપે છે પણ તે કયું ખાતું ચલાવે છે તે બદલતું નથી. જે કામ કરે છે તે ત્રણ ભાગનું હસ્તાંતરણ છે, જેમાં વિશેષાધિકાર પ્રાપ્ત પગલું કહે છે કે શું થયું અને એક અલગ એકમ યોગ્ય ઓળખ હેઠળ ક્રિયા કરે છે.

પર્યાવરણમાંનું વપરાશકર્તા નામ ઓળખ સ્વિચ નથી

Unix નક્કી કરે છે કે પ્રક્રિયા શું સ્પર્શ કરી શકે તે તેના અસરકારક વપરાશકર્તા ID પરથી, તેના પર્યાવરણની શબ્દમાળાઓ પરથી નહીં. USER=alice સેટ કરવું કે LOGNAME નિકાસ કરવું તે બદલે છે કે બેદરકાર સૉફ્ટવેર તેના આઉટપુટમાં શું છાપે છે; ફાઇલ માલિકીની ચકાસણીમાં તે કંઈ બદલતું નથી. તે ચલ સેટ હોય તેવો root તરીકે ચાલતો હૂક હજી પણ Alice ની ફાઇલો root તરીકે ખોલે છે.

નામો પણ એક જ નામ નથી. રિમોટ ઍક્સેસ લોગિન, સ્થાનિક Unix ખાતું અને પ્રમાણપત્રનું સામાન્ય નામ એ ત્રણ ઓળખકર્તા છે જે ઘણી વાર એકરૂપ થાય છે અને ક્યારેક નહીં. a.smith તરીકે પ્રમાણીકરણ કરતા વપરાશકર્તાનું સ્થાનિક ખાતું ન પણ હોય, અથવા ડિરેક્ટરી સેવા દ્વારા તે asmith પર મેપ થઈ શકે. એક શબ્દમાળા ત્રણેય ભૂમિકા ભજવશે એવું ધારતી કોઈપણ રચના પહેલા કોન્ટ્રાક્ટર પર તૂટી પડશે.

તેથી પહેલો પ્રશ્ન «કયો વપરાશકર્તા જોડાયેલો છે» નહીં, પરંતુ «કયું સ્થાનિક ખાતું આ ક્રિયા કરવાની પરવાનગી ધરાવે છે» છે. તેનો જવાબ તમારા પોતાના ખાતા ડેટાબેઝમાંથી આપો, ક્લાયન્ટે મોકલેલા ડેટામાંથી નહીં:

id -u alice
getent passwd alice | cut -d: -f1,3,6
stat -c '%U:%G %a %n' /home/alice/.local/state/vpn-status.json

ત્રીજો આદેશ એ છે જે લોકો છોડી દે છે. જો લક્ષ્ય ફાઇલ root ની માલિકીની હોય કારણ કે અગાઉના હૂકે તે બનાવી હતી, તો યોગ્ય રીતે રૂપરેખાંકિત વપરાશકર્તા-ક્રિયા પરવાનગી ભૂલ સાથે નિષ્ફળ જશે જે systemd સમસ્યા જેવી લાગે છે અને છે નહીં.

ડેમન જ્યાં છે ત્યાં જ રહે છે

VPN સેવાનું પોતાનું User= Alice પર બદલવું ખોટો લિવર છે. તે બદલે છે કે ડેમન ઇન્ટરફેસ કેવી રીતે બાંધે છે, કી કેવી રીતે વાંચે છે, તેની સ્થિતિ ફાઇલ કેવી રીતે લખે છે અને રૂટ કેવી રીતે સંભાળે છે, અને તે બધું જોખમ એક કામ કરતા એકમમાં ખસેડે છે. ડેમનને તેના વિશેષાધિકારોની જરૂર છે; પછીની ક્રિયાને નહીં.

એકમને સ્પર્શ કરતા પહેલા તે ખરેખર શું કરે છે તે જુઓ. બે આદેશ તમને ચલાવવાની ઓળખ અને અમલમાં રહેલી ચોક્કસ આદેશ લાઇનો જણાવે છે, ઓવરરાઇડે ઉમેરેલું બધું પણ સહિત:

systemctl show -p User -p Group -p ExecStart openvpn-server@server
systemctl cat openvpn-server@server

ડિફૉલ્ટ પેકેજ ઇન્સ્ટોલ પર ડેમન root છે અને --up સ્ક્રિપ્ટ તે વારસામાં લે છે. ધારવાને બદલે તેની પુષ્ટિ કરો, કારણ કે કઠોર કરેલું વિતરણ તેને સમર્પિત ખાતા પર ખસેડ્યું હોઈ શકે, અને હાથે લખાયેલું drop-in હૂકને અલગ નિયમોવાળા રૅપર દ્વારા ચલાવી શકે.

ત્રણ નામાંકિત ભાગ, એક સાંકડું ટ્રિગર

જાળવણીમાં ટકી રહેતી ગોઠવણમાં ઘટના, ટ્રિગર અને ક્રિયા હોય છે. ડેમન જણાવે છે કે નામાંકિત સત્ર ઉપર આવ્યું. ટ્રિગર તે નાની હકીકત સ્વીકારે છે અને એક નિશ્ચિત ક્રિયા માગે છે. ક્રિયા તે સ્થાનિક ખાતા હેઠળ ચાલે છે જે સ્પર્શેલી ફાઇલોની માલિક છે. સાંકળમાં કંઈપણ મનસ્વી આદેશ માર્ગ સ્વીકારતું નથી.

ક્રિયા પોતે એક સામાન્ય સેવા એકમ છે, અને ઓળખ તેની અંદરનું એક નિર્દેશ છે:

[Service]
Type=oneshot
User=alice
Group=alice
ExecStart=/usr/local/bin/refresh-vpn-status --slot %i

નોંધો કે User=alice સમગ્ર એકમ પર લાગુ પડે છે, અને systemd એક એવી અપવાદ નોંધે છે જે જાણવા જેવી છે: + ઉપસર્ગવાળો આદેશ તેમ છતાં પૂર્ણ વિશેષાધિકારો સાથે ચાલે છે. તે ઉપસર્ગ એક વિશેષાધિકાર પગલા માટે કાયદેસર સાધન છે અને તમે હમણાં બનાવેલું અલગીકરણ રદ કરવાની અનુકૂળ રીત છે, તેથી તે એકમમાંના કોઈપણ + ને સમીક્ષામાં ન્યાયી ઠેરવવા પડે તેવી વસ્તુ ગણો.

ટ્રિગરનું ઇનપુટ ન્યૂનતમ અને ગુપ્ત-રહિત રાખો. સત્ર ઓળખકર્તા, મેપ કરેલું ખાતું અને સમયચિહ્ન સામાન્ય રીતે જરૂરી હોય તે બધું છે. ક્યારેય શેલ-ટુકડો, ચલાવી શકાય તેવી ફાઇલનો માર્ગ કે ક્લાયન્ટે આપેલો પર્યાવરણ-બ્લોક સીમા પાર ન મોકલો, કારણ કે પ્રાપ્ત કરનાર પાસે કાયદેસર મૂલ્ય અને ઇન્જેક્ટ કરેલા મૂલ્ય વચ્ચે ભેદ પાડવાનો કોઈ રસ્તો નથી.

ખરેખર ચાલેલી ઓળખ ચકાસો

રૂપરેખાંકન સમીક્ષા પુરાવો નથી. મંજૂર પરીક્ષણ કનેક્શન પછી, ફાઇલને સ્પર્શેલા UID ની અને ડેમન હજી વાપરતા UID ની પુષ્ટિ કરો:

stat -c '%U %G %y %n' /home/alice/.local/state/vpn-status.json
ps -o user=,pid=,cmd= -p "$(pgrep -o -f 'openvpn --daemon')"
systemd-run --uid=alice --pipe /usr/local/bin/refresh-vpn-status --dry-run

પહેલી લાઇન Alice અને તમારા પરીક્ષણ વિન્ડોની અંદરનું સમયચિહ્ન દર્શાવવી જોઈએ. બીજીએ હજી root કે પેકેજનું સેવા ખાતું દર્શાવવું જોઈએ, જે સાબિત કરે છે કે ડેમન ખસ્યું નથી. ત્રીજી વાસ્તવિક ફરી-જોડાણની રાહ જોયા વિના ક્રિયાની પરવાનગીઓ ચકાસવાનો સૌથી સસ્તો રસ્તો છે.

જો ફાઇલનો માલિક Alice હોય પણ તેનું જૂથ કે મોડ ચલાવો વચ્ચે બદલાયું હોય, તો તર્કની ભૂલને બદલે UMask= કે ડિરેક્ટરી પરવાનગીનો તફાવત શોધો. જો સમયચિહ્ન બિલકુલ ખસ્યું ન હોય, તો ટ્રિગર ક્યારેય ચાલ્યું જ નહીં, અને ઉપયોગી આગળનું પગલું બીજું ક્લાયન્ટ ફરી-જોડાણ નહીં, પરંતુ ક્રિયા એકમ માટે journalctl -u છે.

કનેક્શન ઘટના હજી પણ શું સાબિત કરતી નથી

સ્થાપિત ટનલ એ એક હકીકત છે. તેનો અર્થ એ નથી કે ડેસ્કટોપ સત્ર ખૂલ્યું છે, સત્ર બસ સુધી પહોંચી શકાય છે, અથવા ક્રિયા જે ખાનગી સંસાધન ઇચ્છે છે તે હવે ઉપલબ્ધ છે. Alice ના UID હેઠળનું oneshot એકમ તેની ઓળખ ધરાવે છે અને તેના સત્રમાંથી કંઈ નહીં, તેથી ગ્રાફિકલ બસ જરૂરી હોય તેવું દરેક વસ્તુને સમર્થિત વપરાશકર્તા-સત્ર પદ્ધતિમાંથી પસાર થવું પડશે અને તે લૉગ આઉટ હોય ત્યારે શું થાય તે વ્યાખ્યાયિત કરવું પડશે.

ફરી-જોડાણો પણ પુનરાવર્તન પામે છે. ટ્રેનમાં ઊંઘતું લૅપટૉપ એક કલાકમાં ડઝન જેટલી કનેક્શન ઘટનાઓ પેદા કરી શકે છે, અને દર વખતે એક લાઇન ઉમેરતો હૂક સ્થિતિ ફાઇલને એવા લોગમાં ફેરવે છે જે કોઈ વાંચી શકતું નથી. ક્રિયાને નિષ્ક્રિય-પુનરાવર્તી બનાવો, અથવા સત્ર-કીવાળા એક જ રેકોર્ડને બદલવા દો.

છેલ્લે, એકમની અંદર જ નુકસાનની ત્રિજ્યા મર્યાદિત કરો: સ્થિતિ ડિરેક્ટરી સિવાય ફક્ત-વાંચી શકાય તેવું ફાઇલસિસ્ટમ દૃશ્ય, નવા વિશેષાધિકારો નહીં, અને સ્પષ્ટ સમયમર્યાદા. ડેમન અને વપરાશકર્તા-ક્રિયા વચ્ચેનું અલગીકરણ પોતાનામાં મૂલ્યવાન છે, પણ જ્યારે ક્રિયા તમે મંજૂર કરેલી તે એક જ વસ્તુ સિવાય બીજું કંઈ કરી શકતી નથી ત્યારે તે ઘણું વધુ મૂલ્યવાન છે.