VPN కనెక్షన్ తర్వాత చర్యను డెమన్గా కాదు, వినియోగదారుగా నడపండి

VPN డెమన్పై కనెక్షన్ hook లు డెమన్గానే నడుస్తాయి, సాధారణంగా దాని అర్థం అవి root గా నడుస్తాయి. ఆ hook లలో ఒకటి ఎవరో ఇంటి డైరెక్టరీలో రాసినా లేదా డెస్క్టాప్ సహాయకుడిని మళ్లీ ప్రారంభించినా, మీరు ఒక నెట్వర్క్ సంఘటనకు ఏదైనా స్థానిక వినియోగదారుగా పని చేసే సామర్థ్యాన్ని ఇచ్చారు. సాధారణ చిన్న దారి, అంటే పరిసర చర నుంచి వినియోగదారు పేరును చదివి దాన్ని ముందుకు పంపడం, దాన్ని సరిచేయదు. అది చర్యకు మళ్లీ లేబుల్ పెడుతుంది, కానీ ఏ ఖాతా దాన్ని అమలు చేస్తుందో మార్చదు. పని చేసేది మూడు భాగాల అప్పగింత, అందులో ప్రత్యేక అధికారం ఉన్న అడుగు ఏం జరిగిందో చెబుతుంది, ప్రత్యేక యూనిట్ సరైన గుర్తింపుతో చర్యను చేస్తుంది.

పరిసరంలోని వినియోగదారు పేరు గుర్తింపు స్విచ్ కాదు

Unix ఒక ప్రక్రియ ఏమి తాకగలదో దాని ప్రభావవంతమైన వినియోగదారు ID ద్వారా నిర్ణయిస్తుంది, దాని పరిసరంలోని స్ట్రింగ్ల ద్వారా కాదు. USER=alice సెట్ చేయడం లేదా LOGNAME ఎగుమతి చేయడం నిర్లక్ష్య సాఫ్ట్వేర్ తన అవుట్పుట్లో ఏమి ముద్రిస్తుందో మారుస్తుంది; ఫైల్ యాజమాన్య తనిఖీల్లో ఏమీ మార్చదు. ఆ చర సెట్ చేసిన స్థితిలో root గా నడిచే hook ఇప్పటికీ root గానే Alice ఫైళ్లను తెరుస్తుంది.

పేర్లు కూడా ఒకే పేరు కావు. దూర ప్రాప్యత లాగిన్, స్థానిక 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 సొంతం అయితే, మునుపటి hook దాన్ని సృష్టించినందున, సరిగా కాన్ఫిగర్ చేసిన వినియోగదారు చర్య systemd సమస్యలా కనిపించే, కానీ కాని అనుమతి లోపంతో విఫలమవుతుంది.

డెమన్ తన చోటే ఉంటుంది

VPN సేవ యొక్క సొంత User= ను Alice కు మార్చడం తప్పు మీట. ఇది డెమన్ ఇంటర్ఫేస్లను ఎలా బంధిస్తుంది, కీలను ఎలా చదువుతుంది, తన స్థితి ఫైలును ఎలా రాస్తుంది మరియు మార్గాలను ఎలా నిర్వహిస్తుంది అనేది మారుస్తుంది, ఆ మొత్తం ప్రమాదాన్ని పని చేస్తున్న యూనిట్లోకి మారుస్తుంది. డెమన్కు దాని ప్రత్యేక అధికారాలు కావాలి; తదుపరి చర్యకు కావు.

యూనిట్ను తాకే ముందు అది నిజంగా ఏమి చేస్తోందో చూడండి. రెండు ఆదేశాలు అమలు గుర్తింపును మరియు అమలులో ఉన్న ఖచ్చితమైన ఆదేశ పంక్తులను చెబుతాయి, ఓవర్రైడ్ జోడించిన అన్నింటితో సహా:

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

డిఫాల్ట్ ప్యాకేజ్ ఇన్స్టాల్లో డెమన్ root, --up స్క్రిప్ట్ దాన్ని వారసత్వంగా పొందుతుంది. ఊహించడం బదులు దాన్ని నిర్ధారించండి, ఎందుకంటే కఠినీకరించిన పంపిణీ దాన్ని ప్రత్యేక ఖాతాకు తరలించి ఉండవచ్చు, చేతితో రాసిన drop-in వేరే నియమాలున్న ర్యాపర్ ద్వారా hook ను నడపవచ్చు.

మూడు పేరున్న భాగాలు, ఒక సన్నని ట్రిగ్గర్

నిర్వహణను తట్టుకునే అమరికలో ఒక సంఘటన, ఒక ట్రిగ్గర్ మరియు ఒక చర్య ఉంటాయి. డెమన్ పేరున్న సెషన్ పైకి వచ్చిందని నివేదిస్తుంది. ట్రిగ్గర్ ఆ చిన్న వాస్తవాన్ని అంగీకరించి ఒక స్థిర చర్యను కోరుతుంది. చర్య తాను తాకే ఫైళ్ల యజమాని అయిన స్థానిక ఖాతా కింద నడుస్తుంది. గొలుసులో ఏదీ ఏకపక్ష ఆదేశ మార్గాన్ని అంగీకరించదు.

చర్య స్వయంగా ఒక సాధారణ సేవా యూనిట్, గుర్తింపు అనేది దానిలోని ఒక ఆదేశం:

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

User=alice మొత్తం యూనిట్కు వర్తిస్తుందని గమనించండి, మరియు systemd తెలుసుకోదగిన ఒక మినహాయింపును నమోదు చేస్తుంది: + ఉపసర్గ ఉన్న ఆదేశం దాన్ని లెక్కించకుండా పూర్తి అధికారాలతో నడుస్తుంది. ఆ ఉపసర్గ ఒకే ప్రత్యేకాధికార అడుగుకు చట్టబద్ధమైన సాధనం మరియు మీరు ఇప్పుడే నిర్మించిన విభజనను రద్దు చేసే సౌకర్యవంతమైన మార్గం, కాబట్టి ఆ యూనిట్లోని ఏ + నైనా సమీక్షలో సమర్థించవలసిన విషయంగా పరిగణించండి.

ట్రిగ్గర్ ఇన్పుట్ను కనిష్ఠంగా, రహస్యం కానిదిగా ఉంచండి. సెషన్ గుర్తింపు, మ్యాప్ చేసిన ఖాతా మరియు సమయ ముద్ర సాధారణంగా అవసరమైనవన్నీ. సరిహద్దు ఆవలికి ఎప్పుడూ shell శకలం, అమలు చేయగల ఫైల్ మార్గం లేదా క్లయింట్ అందించిన పరిసర బ్లాక్ను పంపకండి, ఎందుకంటే స్వీకరించే వైపుకు చట్టబద్ధమైన విలువను ఇంజెక్ట్ చేసిన దాని నుంచి వేరు చేసే మార్గం లేదు.

నిజంగా నడిచిన గుర్తింపును ధృవీకరించండి

కాన్ఫిగరేషన్ సమీక్ష సాక్ష్యం కాదు. ఆమోదించిన పరీక్ష కనెక్షన్ తర్వాత, ఫైలును తాకిన 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 యూనిట్కు ఆమె గుర్తింపు ఉంది, ఆమె సెషన్ నుంచి ఏమీ లేదు, కాబట్టి గ్రాఫికల్ బస్ అవసరమయ్యే ప్రతిదీ మద్దతు ఉన్న వినియోగదారు సెషన్ యంత్రాంగం ద్వారా వెళ్లాలి మరియు ఆమె లాగ్ అవుట్ అయినప్పుడు ఏమి జరుగుతుందో నిర్వచించాలి.

పునఃకనెక్షన్లు కూడా పునరావృతమవుతాయి. రైలులో నిద్రిస్తున్న ల్యాప్టాప్ గంటలో డజను కనెక్షన్ సంఘటనలను సృష్టించగలదు, ప్రతిసారీ ఒక పంక్తిని జోడించే hook స్థితి ఫైలును ఎవరూ చదవలేని లాగ్గా మారుస్తుంది. చర్యను ఐడెంపోటెంట్ చేయండి, లేదా సెషన్ కీతో ఉన్న ఒకే రికార్డును భర్తీ చేయనివ్వండి.

చివరగా, హాని వ్యాసార్థాన్ని యూనిట్ లోపలే పరిమితం చేయండి: స్థితి డైరెక్టరీ బయట చదవడం-మాత్రమే ఫైల్సిస్టమ్ వీక్షణ, కొత్త ప్రత్యేకాధికారాలు లేవు, మరియు స్పష్టమైన కాల పరిమితి. డెమన్ మరియు వినియోగదారు చర్య మధ్య విభజన తనంతట తానే విలువైనది, కానీ చర్య మీరు ఆమోదించిన ఒక విషయం తప్ప ఇంకేమీ చేయలేనప్పుడు అది చాలా ఎక్కువ విలువైనది.