Persoonlijke map in Ubuntu wordt standaard onleesbaar voor nieuwe accounts

De home directories van nieuwe accounts in Ubuntu zijn vanaf versie 21.04 niet langer world-readable. Dit betekent dat bij het aanmaken van een nieuw account, de bestanden in de home directory van dit account niet langer leesbaar en uitvoerbaar zijn door andere accounts.

Alex Murray, security tech lead bij Ubuntu, legt op de Ubuntu-site uit dat het standaard world-readable maken van nieuwe accounts niet meer van deze tijd is. Deze functie was volgens Murray vroeger handig, toen computers gedeeld werden door meerdere mensen die graag eenvoudig bestanden met elkaar zouden willen delen. Inmiddels zou een aanzienlijk deel van de Ubuntu-computers in de cloud- en serversector gebruikt worden. Bij deze computers is er vaak sprake van een adminaccount en meerdere niet-admin gebruikersaccounts. In deze situatie is deze functie eerder een footgun die voor beveiligingsissues kan zorgen. Zo heeft een cybercrimineel bij zo'n computer eenvoudiger toegang tot gevoelige data die in de andere persoonlijke mappen aanwezig kan zijn.

Daarom heeft Murray het /etc/adduser.conf-bestand aangepast, waarbij DIR_MODE=0755 wordt vervangen door DIR_MODE=0750. Daardoor zijn de bestanden in de persoonlijke folder van nieuwe accounts die via adduser worden toegevoegd, niet meer standaard te lezen en uit te voeren door de andere gebruikers. Ook bij het aanmaken van een account op een nieuw systeem wordt de persoonlijke map ontoegankelijk gemaakt voor nog aan te maken gebruikers.

De aangepaste instelling komt via de 21.04-Hirsute Hippo-update naar Ubuntu, waarvan de final release voor 22 april gepland staat. Bestaande accounts worden door de update niet veranderd, bestanden in de persoonlijke map van deze accounts zijn dus nog steeds te gebruiken door andere accounts, tenzij eerder aangepast.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (95)

Voor de mensen die vaak "sudo" vergeten voor een commando en dan, net als ik, gefrustreerd raken dat je allemaal moeite moet doen om 'pijltje-omhoog, home, "sudo" typen, en dan op enter moet drukken, is er natuurlijk ook het "please" alias:

alias please='sudo "$BASH" -c "$(history -p !!)"'

Bijv.

# apt install foobar
> Nee mag niet fout.
# please
> okay.....

Of sudo !!

Btw, je quote lijkt al op een root shell

Dan krijg je dus:

alias please='sudo !!'

Voordeel is dat dit niet af hangt van commando's als history en je BASH env var. Werkt dus ook gewoon in ZSH bijvoorbeeld.

Dan krijg je dus:
alias please='sudo !!'

Dit lijkt niet te werken.
"sudo !!" kan (schijnbaar) geen aliassen volgen en probeert daarom het commando 'please' (opnieuw) uit te voeren i.p.v. het eerder door de gebruiker ingetypte commando.

Tenminste: ik krijg als output:

sudo: please: command not found

Edit: output toegevoegd

[Reactie gewijzigd door T-men op 14 januari 2021 09:27]

is ook niet echt nuttig je bespaart met please maar 1 character tov sudo !!

Dan kun je nog dit proberen:

alias please='sudo !-2'

... of -3 etc

Zelf gebruik ik gewoon sudo !! maar ik vind het idee wel leuk

Dat is wel enorm handig! Ik ga dit meteen toevoegen in mijn aliases!

edit: dit werkt niet vanuit een alias bij mij. Dan probeert zsh !! uit te voeren als command.

[Reactie gewijzigd door mjz2cool op 14 januari 2021 08:46]

sudo !!

https://xkcd.com/149/ sudo make me a sandwich...

Of maak er " now " van...

# apt install foobar
> Nee mag niet
# now
> ok!

Of "fuck"
1 van mijn favo tools.

➜ apt-get install vim
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

➜ fuck
sudo apt-get install vim [enter/↑/↓/ctrl+c]

Dan alias fucking='sudo'. Dan kun je zeggen "fucking apt update" etc.

Briljant dit!!!
Wou dat ik eerder dit tegengekomen was.
(Breinloos ‘sudo’ en cmd herhalen zit er helaas heel diep ingebakken na 21 jaar...sinds SuSe 6.0 en de switch naar Debian heb ik weinig nieuwe, goede gewoontes voor de shell bijgeleerd. )

Je zou ook de github app genaamd thefuck gebruiken. Ik heb 'm ooit gezien bij een presentatie waarbij iemand ook vergat sudo voor een command te gebruiken.

Dit gifje geeft een idee van hoe/wat: https://raw.githubusercon...hefuck/master/example.gif

[Reactie gewijzigd door .je op 15 januari 2021 09:13]

Toch een beetje jammer dat het meer dan tien jaar heeft geduurd..

https://bugs.launchpad.ne...ource/adduser/+bug/675560

Meer dan veertien jaar blijkbaar: https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734

[Reactie gewijzigd door Olaf van der Spek op 13 januari 2021 21:54]

Ik vond het ook altijd een beveiligingslek, en een doorn in het oog. Onbegrijpelijk.

Uberhaupt ACL op linux is, voor mij persoonlijk, een drama. Het is alles behalve gebruiksvriendelijk, standaard tools kunnen er niet mee omgaan (file copy/move) "is gewoon gewenst gedrag hoor", etc..

Ze mogen wel wat leren van Windows op dit vlak

[Reactie gewijzigd door grasmanek94 op 14 januari 2021 08:52]

Alsof Windows zo'n goed systeem heeft. Dat is een afgeleide van hoe VMS werkte. Probeer maar eens op een hele grote folder met X subfolders en XXX files de rechten aan te passen. Dat duurt minuten, soms zelfs uren. Ik ben zelf Novell gewend geweest, dat was veel prettiger. Maar ja... een goed product verkoopt zichzelf niet; goede marketing verkoopt een product, dus hebben we Windows met NTFS.

Ook Windows neemt bij het kopiëren/verplaatsen van folders standaard de NTFS rechten niet mee, behalve wanneer je de folder binnen dezelfde partitie verplaatst. Dit is trouwens wel op te lossen door iets te wijzigen in de registry, zodat windows explorer toch de rechten mee neemt.

Ik zei gelukkig niet dat Windows perfect is, liefst switch ik naar iets anders. Maar het werkt voor de eind gebruiker zeker vlotter dan als men dezelfde doelen ergens anders wil bereiken (ik weet niet hoe het op MacOS is, maar ik dacht dat daar ook de standaard chmod/chown/ACLs zijn? ik weet het niet).

En zeker, rechten moet je per file aanpassen, dat kan erg lang duren. Windows, bij inheritance, past per file copy de ge-inherite rechten automatisch toe. Kopieren van 100k files gaat dan lang duren, of men nou een SSD heeft of niet.

Ook bij het delen voor netwerktoegang worden de rechten per file aangepast (tenzij men advanced sharing gebruikt, dan werkt het opeens anders/sneller/beter? magie?).

Wanneer een file via netwerk wordt aangemaakt, neemt de file wel de correcte inheritance/ACLs over, die ervaring is op Linux helemaal anders voor mij persoonlijk.

[Reactie gewijzigd door grasmanek94 op 14 januari 2021 11:33]

Permissions van files en directories zijn juist in windows een drama:

Als je een externe disk gebruikt die op een andere windows installatie is aangemaakt dan is er geen fatsoenlijke manier om de rechten goed te krijgen, omdat er simpelweg te veel verschillende users en groups aan een file of dir kunnen hangen.

Bij Unix en Linux is de aanpak veel simpeler, wat in 99% van de gevallen ook gewoon voldoende is.

In linux heb je users en groups met een eigen id. Op file en directory level kan je ids van de owneren group zetten. Verder kan je de rechten per file/dir open en dichtzettenen voor owner, group en world.

Als root/admin kan je dit altijd Linux, onder windows lukt dit niet altijd.

Dat laatste klopt niet. Als Administrator heb je altijd admin rechten op de root folder van je disk, en daarmee kun je alle onderliggende permissies aanpassen.

Een belangrijk verschil met Linux is dat Windows de officiële beveiligingseisen volgt, wat betekent dat een Administrator dit niet ongemerkt kan doen. Je moet het eigendom van de subdirectories overnemen.

'Is overigens niet een probleem met andere Windows "installaties"; het is een probleem met niet-gekoppelde gebruikersdomeinen. Windows PC's in een bedrijfsnetwerk met Actvie Directory kennen elkaar's users, maar Windows 10 Home kent alleen lokale gebruikers en Microsoft accounts.

Uhm, op Linux heeft elk user account wel een ID. Het komt net goed uit dat dat ID vaak het 1e gebruiksaccount is, dus "Alice" op PC A, en "Bob" op PC B, als de files op de USB dan van de "user" zijn, en je doet ls -al, krijg je 2 verschillende eigenaren afhankelijk van het systeem.

Als de 5e gebruiker op PC A bestanden op USB zet, en vervolgens deze in PC B stopt (met gebruiker 1 ingelogd), komt diegene zonder root ook niet in de files (als de 5e gebruiker eigenaar/groep is, met xx0 rechten).

Op Windows, gaat dit door gegenereerde, willekeurige, "SID"s.
Ja, om er dan bij te komen moet je moeite doen.
Maar als Linux de beveiliging/ACLs juist op orde had, moest je ook moeite gaan doen op een USB stick op Linux.
Wil iemand bestanden delen, dan is het wel ongebruiksvriendelijk dat ze expliciet toegankelijk moet geven - akkoord.
Maar zo ziet we weer, gebruiksvriendelijkheid <=> beveiliging.

[Reactie gewijzigd door grasmanek94 op 14 januari 2021 14:28]

Ook bij het delen voor netwerktoegang worden de rechten per file aangepast (tenzij men advanced sharing gebruikt, dan werkt het opeens anders/sneller/beter? magie?.

Die sharing wizard in Windows zou niemand ooit moeten gebruiken. Wat dat doet, is zowel een share maken als NTFS permissies aanpassen. Dat doet 't echter heel krom. Wanneer je namelijk via die wizard iemand READ/WRITE recht geeft, kijk dan maar eens wat voor NTFS rechten die in de praktijk heeft gekregen.... FULL CONTROL!!!!!

Het is altijd beter om Advanced Sharing te gebruiken. Daarmee maak je enkel de share en pas je de NTFS rechten niet aan. Bij Advanced Sharing moet je nog wel even kijken naar de share permissies, want standaard krijgt iedereen READ.
Oh... en SHARE permissies geven geen extra recht! Ze geven alleen aan hoeveel NTFS rechten je vanaf het netwerk mag gebruiken. Dus wanneer je bijvoorbeeld Modify NTFS rechten hebt, maar de SHARE permissie is READ, dan mag je maximaal met READ naar binnen. Wanneer de SHARE permissie op FULL CONTROL staat, dan krijg je dus geen extra rechten, maar houd je de Modify NTFS rechten.
Veel mensen leggen dit uit als "Most Restrictive" maar eigenlijk klopt dit dus niet: SHARE permissies geven namelijk geen rechten, maar zetten alleen het deurtje vanaf het netwerk op een kiertje met READ, iets verder open met CHANGE en helemaal open met FULL CONTROL.

MAC OS blijft een Free BSD afstameling en doet dit niet heel veel beter binnen de bash/shell moet je nog steeds root rechten hebben voor veel dingen en ze hebben voor dingen als installers van internet een heel hinderlijke route ingebouwd dat je via control panel bij privacy als nog toestemming moet geven met je admin password om iets te draaien dan is de windows manier sneller en makkelijker weet u het zeker ja ok wachterwoord graag.

Linux blijft simpeler maar voor veel dingen toch blijven haken in windows.

Het grote voordeel van Windows is in elk geval dat het 1 systeem is.

Linux heeft wel degelijk ACL's, maar dat is niet waar dit artikel over gaat. De "750" uit het artikel zijn de oude Unix permissie bits, 3x3 (user/group/word, read/write/execute). Dat is simpelweg onvoldoende voor een omgeving met enige security eisen, vandaar dat Linux een tweede set commando's heeft om ACL's te gebruiken (setfacl ipv chmod). Maar de bulk van de Linux tools kent alleen de oude bits, en het mixen van oude permissies en nieuwe ACL's levert ook regelmatig verwarring op.

Ja, dat weet ik. Behalve dat ik Microsoft trainingen geef, heb ik ook Linux trainingen gegeven.

Maar dit is erg OT.

ACL op linux is een drama want ?

Wanneer ik een copy (cp), of rsync operatie doe, verwacht ik niet elke keer dat ik `man` moet openen en allerlei opties moet gaan uitzoeken om de juiste ACLs mee te kopiëren. Ik zit niet elke dag files te kopiëren. Die tools moeten dat gewoon standaard doen. Kopie is een kopie, exact, punt. Ik snap niet waarom ze in de linux wereld daar anders over denken?
Inheritance instellen is ook helemaal anders dan mijn "verwachtingen", en werkt ook niet altijd zoals ik verwacht (ik interpreteer de manpages schijnbaar fout?) - en soms werkt het helemaal niet. Als er top-directory inheritance enabled is, neem die ge-inherite permissies dan over (zou je denken) als men paar lagen dieper files erin zet. Nope: access denied. Zal wel aan mij liggen (ik heb geen master-diploma in ext4-ACL ).

Verder heb je chmod, chown,... en dan denk je dat je alles kan, maar nee, je mag lekker de manpages gaan uitvogelen voor setfacl en getfacl met andere syntax! Wil je de normale permissies checken: ls, ACL: getfacl. Lekker.. maar of het nou aan mij ligt of niet: gebruiksvriendelijk is het niet, en het gaat makkelijk fout.

Als ik kon kiezen had ik op zijn minst ervoor gekozen om heel het chmod/chown systeem eruit gooien en _alleen_ ACL (getf/setf) te gebruiken.

En na dat alles.. komt men nog eens even op samba/network sharing, wat heb ik daar buitenproportioneel veel uitzoekwerk voor moeten doen om access denied daar op te lossen (en aanmaken van files door de netwerkgebruiker met de juiste ge-inherite permissies laten zijn is ook een drama).

Ik merk na al dat gedoe, dat Windows mensen van heel veel gemakken voorziet. Doet veel voor de gebruiker (netwerk file sharing werkt gewoon als je een account toegang geeft tot een netwerk folder, hoef je niet zelf ACLs aan te gaan passen, inheritance werkt gewoon zoals een leek dat zou verwachten bij standaard copy operaties, permissies worden mee gekopieerd voor zover dat mogelijk is, etc, zonder dat ik, die ene keer per maand dat ik dat nodig heb, een uur in manpages moet duiken).

Aan chroot/sftp ben ik niet eens begonnen (na de eerste paar minuten googlen/manpages lezen), om te zorgen dat sftp gebruikers "100% zeker weten" niet bij "andere" files kunnen (ook niet directories met xx7 en files die publiek leesbaar zijn) dan alleen files in hun home directory.. ik heb hiervoor maar een virtuele machine voor opgericht die alleen bij de bestanden op de host kan waar de gebruikers toegang tot mogen hebben. Dat is stom, maar de enige manier waarop ik zelf veiligheid kan garanderen, want op een andere manier kan ik dat niet garanderen (heb al vaak zat fouten met ACLs gemaakt, en sftp/chroot/jail+ACLs+tegelijk normale SSH/sftp toegang tot host garanderen voor admin accounts is nog complexer).

[Reactie gewijzigd door grasmanek94 op 14 januari 2021 09:55]

rsync is wel een compleet ander beestje dan een copy; cp -a neemt toch gewoon alle permissies mee over ?

Linux heeft standaard DAC (discretion access control), waar eigenlijk de owner beslist wie zijn files kan zien/execute/write, in de Windows wereld zijn we net gewent dat iemand anders dat voor ons beslist; Maar dat kan met selinux ook natuurlijk dat is MAC (mandatory access control)...

Overigens ben je met een ext4 diploma niet veel verder dat is namelijk gewoon het filesysteem
chrooten zorgt bij mijn weten ook voor dat je niet uit je jail komt dus al staat dan nog je hele filesysteem als 777 dan nog kan je niet uit de jail. (exploits daar gelaten)

Windows geeft gemak, tegen de prijs van veiligheid zou ik zo denken; getfacl heb ik eerlijk gezegd nog niet zo vaak nodig gehad ...

De laatste keer dat ik windows shares moest opzetten dan pas is het een drama, je hebt "shares", je hebt NTFS shares, je hebt advanced shares, ...

Smaak & voorkeur zeker ?

cp -a kopieert dan weer helaas niet file capabilities ( https://www.insecure.ws/linux/getcap_setcap.html ), schijnbaar een bug ( https://lists.gnu.org/arc...ils/2010-04/msg00105.html ), maar die "fix" zit niet in Ubuntu 18?
Resultaat: brak systeem na mergen van 2 file systemen.Kwam ik ook pas achteraf achter
Nu is dat op Windows ook niet zo 1-2-3 makkelijk (en op linux makkelijker denk ik), maar "robocopy" werkt verbazend goed (helaas, ook lang documentatie in duiken).

Zeker smaak en voorkeur.

Windows met allerlei verschillende share technologie vind ik ook raar. Ik gebruik gewoon advanced sharing en ben er altijd blij mee geweest.
Maarja alle troep en fouten die ook in Windows aanwezig zijn.. voor mij is de keuze dus: shiny corporate shit A, shiny open source shit B 😂

[Reactie gewijzigd door grasmanek94 op 14 januari 2021 14:15]

Ik denk dat de meeste mensen sowieso niet verder komen dan de normale Linux permissions. En dat 0777 de meeste gebruikte permissie is.

En dit is voor mij de reden dat ik vaak linux gewoon vervelend vind om mee te werken tenzij ik echt maar 1 doel hebt op een linux server en er nooit meer aan hoef te komen nadat ik alles aan de gang heb gekregen.

Het uitzoeken en oplossen kost zo veel meer tijd en dan is het misschien vast heel veilig en geweldig en fanatisch maar ik heb wel wat beters te doen.

Wat is dan precies beter/slechter? Welke standaard tools bedoel je?

cp, rsync, mv

Kunt mijn andere reactie gerust doornemen, onhandig om dubbel hetzelfde te vertellen.

[Reactie gewijzigd door grasmanek94 op 14 januari 2021 09:18]

chmod o-rwx -R ~

Verwijder recursief de lees-schrijf-uitvoer permissies op de home folder

Ik zou daar mee uitkijken. Als je items in je ~/.local/bin of ~/bin hebt worden die ook niet meer uitvoerbaar (voor other, dus moet je jezelf sowieso achter de oren krabben waarom je dat niet in /usr/local/bin hebt staan bijvoorbeeld). Beter los je dit met find op:

sudo find /home -type d -maxdepth 1 -exec chmod o-rwx {} \;

Trouwens, jouw shellcode pakt alles in de home directory, niet de home directory/directories zelf.

[Reactie gewijzigd door sfranken op 13 januari 2021 22:07]

RIP ~/Public

~/Public is bedoelt om bestanden over het netwerk te delen. Dat word gewoon beheerd door een service die als root draait, dus je zal gewoon nog toegang hebben.

Liever chmod -R go-rwx

Toen ik de title las schrok ik even, ik dacht dat ze Systemd-homed standaard gingen gebruiken. Systemd-homed is mooi spul maar geeft mij altijd problemen omdat ik veel met root werk.

Het verbaast mij dat Ubuntu de rechten op deze manier had ingesteld, op de meeste andere distributies zie ik vaak dat de home directory op 700 staat.

Ze zullen het wel initieel zo gedaan hebben om niet-technische gebruikers minder in de weg te zitten met rechten.

Toen ik de title las schrok ik even, ik dacht dat ze Systemd-homed standaard gingen gebruiken. Systemd-homed is mooi spul maar geeft mij altijd problemen omdat ik veel met root werk.

Daar is sudo voor uitgevonden. Werken met de root account is een vrij grote no-no.

Ze zullen het wel initieel zo gedaan hebben om niet-technische gebruikers minder in de weg te zitten met rechten.

Wat heeft een niet-technische gebruiker buiten ~ te zoeken? Ik quote het artikel letterlijk hier:

quote: het artikel

Deze functie was volgens Murray vroeger handig, toen computers gedeeld werden door meerdere mensen die graag eenvoudig bestanden met elkaar zouden willen delen

Nee sudo is voor shared systemen waar sommige gebruikers bepaalde commando's als root kunnen uitvoeren zonder dat ze daarvoor het root wachtwoord voor hoeven weten. Je bent er toch niet zo'n een die elke dag 500 keer sudo voor een commando typt? Doe gewoon gelijk sudo -i. Werken als root is helemaal geen no-go. Ik ken in mijn 10 jaar ervaring als Linux systems expert niemand die overal sudo voor typt. Het beschermt je nergens extra voor als je toch al alles mag met sudo.

Ik gebruik ook nooit sudo. Ik erger me rot als ik een file edit in nano bijv en dan wil saven. No permisson, shit vergeten te sudo-en. Kun je weer opnieuw beginnen.

Zelfde in Windows met UAC, op beheerservers gaat die ook uit bij mij.

Ik gebruik ook nooit sudo. Ik erger me rot als ik een file edit in nano bijv en dan wil saven. No permisson, shit vergeten te sudo-en. Kun je weer opnieuw beginnen.

Zelfde in Windows met UAC, op beheerservers gaat die ook uit bij mij.

Dat stukje met nano is heeeeeel herkenbaar. Je kan ook niet achteraf root rechten verkrijgen om alsnog te saven. Op m’n MacBook doe ik ook veel op root niveau, en daar ben ik blij met Touch ID. Elke keer als de sudo tijd voorbij is even vinger op de Touch ID knop en klaar.

in vim gewoon `:!sudo vim %`

Ik vind nano persoonlijk wat prettiger werken. Ik red me wel met vim, maar voor snel ff wat aanpassingen ben ik nano wat meer meester.

Gelukkig zijn er nog anti sudo'ers! Ik heb het van in het begin ook gehaat en gebruik het zelden....
bij mij is het ook:
su root
(doe je ding)
exit

Er wordt overal geroepen dat dit niet veilig is, maar dat is BS. Ik zeg overigens niet dat sudo geen nut heeft, in multi user systemen komt het bijvoorbeeld wel van pas.

[Reactie gewijzigd door Bigjim80 op 14 januari 2021 08:52]

maar sudo rm -rf * is veel veiliger dan rm -rf * als root !

Ik ga dat commando meteen eens testen op mijn systeem!
(mooi aangetoond trouwens dat sudo vooral een vals gevoel van veiligheid is....)

[Reactie gewijzigd door Bigjim80 op 14 januari 2021 09:30]

of nog leuker: /*

Save je eerst in de user home-directory, daarna via su kopieren en root flags eraan geven.
Maar irritant is het wel ja...

Toch eens de man page lezen, deed altijd sudo su - maar het kan dus korter.

Ja en nee. sudo su - is niet hetzelfde als sudo -i of sudo -s. Maar je merkt het verschil niet.

Ook op servers doe je als het even kan geen sudo -i, of sudo -s, of sudo su - . Je kunt sudo prima instellen dat de tijd tussen wachtwoorden langer is, bijvoorbeeld. Bij vorige werkgevers was "sudo -i" écht een no-go...

Je bent er toch niet zo'n een die elke dag 500 keer sudo voor een commando typt?

Ik wel. Gaat ook eigenlijk automatisch. Zowel prive als professioneel ben ik vrijwel nooit root. Beetje oldschool wellicht, ben in 1998 begonnen

Ik zou gek worden om voor iedere sudo door 2FA te lopen

Blij in ieder geval nog één iemand tegen te komen in deze thread die dat begrijpt. Dat rare gepush van sudo in social media door non-professionals komt heel erg over als ******* meten.
Ik heb het niet eens op mijn systeem.
https://michaeleriksson.w...-sudo-considered-harmful/

Ik gebruik natuurlijk ook sudo. Als ik root file systems bouw om ze vervolgens in een container te stoppen moeten de rechten er goed op staan, root is dus de enige gebruiker die dit kan doen. Onder systemd-homed heeft root geen toegang tot je user home directory gezien die encrypted is.

Ik zat te denken aan het scenario dat is gegeven als het voorbeeld in het artikel, Klaasje wil een bestandje kopiëren uit de home folder van Pietje. Met de nieuwe gebruikersrechten is dit niet meer mogelijk. Dit komt namelijk nog wel voor, alsdan zelden.

Ook het bouwen van container file systemen bouwen behoor je niet onder root te doen. (Maar is wel makkelijk

Er bestaat voor het 2e scenario ook nog zoiets als Access Control Lists.

Access Control Lists heb ik nooit helemaal lekker werkend gekregen. Ik weet niet goed waarom, maar het lijkt alsof de permissies niet altijd goed worden overgenomen. Dan hoor ik ergens rechten toe te hebben omdat ik tot de groep behoor die permissies heeft, maar toch wil het niet. Soms werkt het wel, dus ik weet niet goed wat het nou is. Het principe is wel heel goed. Je kan heel precies bepalen wie er wel en niet toegang heeft, en in principe erven submappen en bestanden die rechten over.

Volgens mij (in mijn herinnering) gaan ACL's niet mee in een TARfile. En ook over nfs gaat het niet altijd goed. Ik weiger ACL's te gebruiken. te veel nét niet.

Ik ben opstandig en heb mijn eigen tools gebouwd. Ik doe een basis installatie van bijv Debian in een directory, installeer dan de software via een chroot met scripts en copy/paste het in een Docker image. Ik vind dit makkelijker te troubleshooten dan Dockerfiles. Ik baseer ook lieven mijn images op de nieuwste software uit de distro repos in plaats van maanden/jaren oude images op Dockerhub.

Oh dat kende ik nog niet. Heb het even opgezocht, het lijkt een beetje alsof ze het roaming profiel van Windows aan het nabouwen zijn. Dit was op Windows nou nooit echt een succes vond ik Dat is helemaal niet iets dat ik op Linux zou willen.

Maar dat heb ik wel met meer dingen van systemd... Ik vind het te ingewikkeld voor wat het doet. Ik ben zelf voor mijn desktop overgestapt naar FreeBSD om die reden (en ook andere dingen die me op Ubuntu irriteerden zoals de snaps), ben er erg blij mee.

De homedir op 755 instellen vind ik trouwens ook niet bepaald handig nee. Op een echt multiuser systeem is dit ongelofelijk fout... Een beetje zoals met X-Terminals in het begin toen er nog geen Xauth bestond en je gewoon je programma's op iemand anders zijn scherm tevoorschijn kon toveren (wel lol mee gehad trouwens).

[Reactie gewijzigd door GekkePrutser op 13 januari 2021 22:25]

Ik ben zelf voor mijn desktop overgestapt naar FreeBSD om die reden (en ook andere dingen die me op Ubuntu irriteerden zoals de snaps), ben er erg blij mee.

Je bent je er van bewust dat Ubuntu niet de enigste distro is die er bestaat?

Yes maar als je niet dol bent op systemd heb je niet zo heel veel keus meer op desktop gebied. (Dat stukje mist net in je quote ). Alle groten zijn nu overgestapt, zelfs arch. Wat er overblijft vind ik te obscuur (ja zelfs Gentoo). Snap was gewoon een extra irritatie op Ubuntu (wat op dat moment mijn belangrijkste desktop was), die er nog bij kwam. Apps starten veel trager op en gebruiken veel meer geheugen. En hij gooit je mounts lijst vol met allerlei troep.

Ik gebruik wel nog Alpine voor servers (met dockers, werkt niet lekker op FreeBSD en de jails zijn toch een beetje anders). Die gebruikt OpenRC. Maar Alpine is niet geweldig voor op een desktop. Ze zijn wel bezig aan een spinoff daarvoor (Adélie Linux) maar dat staat nog in de kinderschoenen. Ze zitten nog in de release candidates van hun 1.0 versie en dit is al een tijd zo, ik volgde ze al langer.

Bovendien heb ik vroeger altijd FreeBSD gebruikt (en 386BSD) en ik wilde eigenlijk wel terug. FreeBSD heeft vele voordelen boven Linux zoals Root on ZFS (Ubuntu begint dit nu ook te krijgen maar zoals gezegd was dat geen optie meer), Jails, de ports collection en uitstekende documentatie. Destijds viel me alleen de hardware support nogal tegen, en de bruikbaarheid als desktop. Het eerste punt is er nog steeds wel een beetje, de tweede is wel opgelost nu

[Reactie gewijzigd door GekkePrutser op 13 januari 2021 23:27]

Ik heb ook jarenlang FreeBSD gedraaid met ZFS als plex server. Maar uiteindelijk naar Debian 10 gegaan omdat het toch altijd een gesukkel was om belaalde dingen werkend te krijgen op FreeBSD.

Het ging allemaal wel maar vaak met de nodige workarounds. Die ports tree vind ik ook een beetje drama. De pkgs die er dan zijn zijn beperkt of lopen altjjd zwaar achter.

Ook is de community support bij Linux een stuk groter.

Neemt niet weg dat ik nog een zwak heb voor FreeBSD en ook zeker voor Gentoo maar het kostte me allemaal teveel tijd.

Het domste aan die ports is dat ze die categorie-namen blijven vasthouden terwijl je gewoon niet kan weten of een willekeurig programma bij devel, misc, networking, math, print of sysutils hoort. Ik heb inmiddels een script get_port_category dat de hele portstree indexeert en de categorie eruit vist, anders ben je iedere keer 10 minuten aan het zoeken.
Een ander link dingetje is dat het systeem de helft van zijn packages van source wil gaan upgraden omdat een of ander betekenisloos programma ineens als zijn dependency-versies heeft aangepast, met of zonder noodzaak. Wil die zijn Xorg, window-manager en compiler-set gaan upgraden omdat een teksteditor van 1.4_3.1 naar 1.4_3.2 is gegaan...

Irritant bij de communnity is dat ze zich overal met smoesjes uit kletsen om het probleem te ontwijken. Ik zou bijvoorbeeld niet beginnen over het feit dat SDIO, en dus wifi op geen enkele SBC met Broadcom wifi werkt... Dat is heel normaal en nergens voor nodig. Het ligt ook nergens aan.

Het grote voordeel is dat het 100% bloat-vrij is. Je kan een kernel met een shell er bovenop en verder niks draaien.

[Reactie gewijzigd door blorf op 14 januari 2021 09:42]

Ja die categorieen zijn wel een dingetje, dat is waar. Ik zoek ze meestal met 'find', maar ook dat is lastig als je de naam niet precies weet.

Je kan ook hier kijken: https://www.freebsd.org/ports/searching.html

Die dependency issues heb ik nog niet gezien maar dat is wel vervelend inderdaad PS: Als je op Linux bloat-vrij zoekt kan ik Alpine heel erg aanraden!

Als je een standaard install hebt voldoet locate ook, alleen gaat ie dan op vrijdagmiddag 16:00 die index zitten updaten.

Dat upgrade probleem is de oude Windows DLL hell. De logische oplossing is dat je installatie's naast elkaar ondersteunt, zodat je teksteditor 1.4_3.1 en 1.4_3.2 naast elkaar kunt hebben. Idealiter zelfs met het delen van files, zodat je op disk geen dubbele ruimte nodig hebt (Zie de WinSxS folder op Windows).

Technisch is het ook geen heel erg groot probleem - je symlinkt simpelweg de files van /packages/teksteditor_1.4_3,1 naar /bin/

In FreeBSD zijn dat .so bestanden. Met ldconfig kun je zelf directories toevoegen aan de actieve base, daar zit het probleem niet. De portstree gaat er gewoon leuk vanuit dat iedereen heel strikt alleen maar dingen daaruit installeert. Als ik daarnaar zou luisteren op mijn PC met uitgebreide installatie waar ook github spullen en handmatig gecompileerde programmatuur tussen zit, zou er onvoorspelbaar van alles breken.

In de ports tree kun je zoeken met make search.

# cd /usr/ports
# make search name=haproxy
of make search key=<search string>

Soms gaat het inderdaad wat moeizaam met maintainers, en soms ook erg snel en direct.
Maar dat heb je ook met Linux, ik heb meer vervelende ervaringen met Linux personen dan FreeBSD personen.

Ik gebruik sinds 4.2 FreeBSD heb nog wel eens gekeken naar Linux, maar het kan mij niet meer bekoren, ja het is snel, ja het is makkelijk maar de kant waar het opgaat met overal maar services die zich overal mee bemoeien lees systemd maakt het geen leuk systeem om mee te werken. Op mijn werk gebruiken we exclusief Ubuntu, maar wat een verademing is het als ik in de avond weer aan mijn prive servertje mag sleutelen.

Laatst met Ubuntu18.04 een geintje met disks vervangen.
Voor mysql data hebben wij een aparte disk, deze gingen wij vervangen door een groter exemplaar.
/var/lib/mysql verwijst naar /data. Nieuwe disk geplaatst, /dev/sdd kreeg deze mee.
/dev/sdd voorzien van een partitie en een bestandssyteem en gemount op /data/data-2.
Mysql gestopt, data gekopieerd van /data naar /data-2. /dev/sdc geunmount, /dev/sdd unmount.
Mountpoints omgedraaid. dus sdd mounten op /data en sdc op /data-2 mocht er wat missen dan kunnen we er nog bij
Mysql starten, de truukjes doen en alles helemaal ok. Even een dagje wachten en dan kunnen we disk sdc verwijderen.
Dus de volgende dag disk verwijdert en wat doet systemd, die weet dat sdc tijdens de boot gemount was op /data, inderdaad deze unmount /data gewoon en tevens blokkeert systemd dat je sdd weer kan mounten op /data.
NIET DOEN, die is nu gemount op sdd. Ofwel je unmount gewoon je data van je database. Dit was een test machine, had geen verder geen gevolgen maar dit was de test voor productie, die we dus live doen op een virtuele machine met de productie data.
Is al sinds 2015 een probleem blijkbaar maar word naar het schijnt niet veel aangedaan.
https://github.com/systemd/systemd/issues/1741

En zo zijn er op ubuntu vele zaken waardoor je echt geen vertrouwen meer hebt in het systeem. Elke release is bijna een nieuw OS, zoveel quirks die je allemaal weer moet zien te vinden. Daarbij is FreeBSD een verademing.

Soms is het inderdaad een gedoe om op FreeBSD iets aan de praat te krijgen, dit omdat FreeBSD je vaak geen compleet werkende config geeft, je zal dus zelf je applicatie moeten configureren.
Maar als ik aan een Ubuntu collega vraag of hij even een apache module wil laden, dan kan de arme drommel alleen maar a2enmod doen. Sommige juniors weten niet eens wat er gebeurt en op een andere unix zijn ze hopeloos verloren omdat men alleen maar de tooling kent die Ubuntu meelevert. Hoe je apache configureerd, ze hebben geen idee.
Dus ja FreeBSD is lastiger, maar je weet als je klaar bent wel hoe en wat en bij problemen heb je vaak veel sneller een idee waar het kan zitten omdat je de config toch echt heb moeten onderzoeken.
Zo heb ik toch heel wat meer geleerd van applicaties dan de ubuntu manier. En ja soms is het ook frustrerend als je snel even iets wil doen.

@Omega
Ga er maar vanuit dat systemd-homed ook gewoon gaat landen in de aankomende Ubuntu versies.

Het probleem met Ubuntu is dat het geen Linux wil zijn, om zich te onderscheiden. Bij "Ubuntu Phone" begon dat op te vallen. Het ging Ubuntu OS zonder Linux in de naam heten en ze zouden de exclusieve permissie krijgen voor smartphones.
Om die reden is het ook geflopt. Mensen zijn gaan graven naar de achterliggende reden, min of meer de vraag waarom andere Linuxen buiten de boot zouden vallen. Toen zijn closed-source monopoly-gerichte praktijken en twijfelachtige deals met fabrikanten boven water gekomen.

FreeBSD heeft een klein beetje last van ditzelfde imperialisme. De pre- en post login-meldingenen mbt OS 'brand', architectuur en versie zijn actief verstopt en vertroebeld in de code van de login executable. Echt open en non-profit zou dit niet moeten steunen.

[Reactie gewijzigd door blorf op 15 januari 2021 13:18]

Nouja het is anders, vooral.. Met Linux heb je meer mensen in de IRC kanalen, maar als je een vraag hebt dan word je vaak genegeerd of met RTFM.

Met FreeBSD heb ik een paar keer dingen aangekaart, en de package dev vroeg me om wat gegevens en heeft daarna meteen een patch doorgevoerd om het probleem te fixen. Dus ja er zijn minder mensen maar je zit wel vaak direct bij de juiste.

En het achterlopen vind ik meevallen, het is minder dan op bijv. Debian in mijn ervaring. De dingen die belangrijk zijn zoals Firefox lopen op de dag toe mee. En het kunnen recompilen van packages (met andere opties) vind ik super handig. Dat zie je op Linux niet echt, behalve de AUR van Arch. Maar dat is toch een beetje anders: De AUR is puur user contributed, en bevat juist niet de apps die ook als package worden meegeleverd terwijl dat bij FreeBSD ports weer wel zo is.

Niettemin vind ik de AUR wel een tof punt van Arch hoor! Alleen wat me weer tegenstond aan Arch is dat er tig manieren zijn om iets te doen (zelfs iets basaals als instellen van je netwerk) en die opties dan weer niet geweldig gedocumenteerd zijn, het is meer anekdotisch vraag/antwoord stijl, terwijl FreeBSD echt een autoritatief handboek heeft. Ook kan je vaak niet terugvinden welke van de X opties die je kan kiezen handig is in welke situatie.

[Reactie gewijzigd door GekkePrutser op 13 januari 2021 23:44]

Nog eens zoeken

Ze zullen het wel initieel zo gedaan hebben om niet-technische gebruikers minder in de weg te zitten met rechten.

Ubuntu is een Debian afgeleidde en bij Debian is 0755 nog de standaard voor nieuwe home mappen. Canonical heeft al die tijd dus die standaard niet verandert, maar doen dat dus met 21.04 wel.

Inderdaad. En ik ben ooit tegen een Debian thread aangelopen waar dit als intentional werd verdedigd, omdat "750 of 700 geen echte security biedt".
Waar dat gammele argument natuurlijk aan voorbij gaat is dat dat het bescherming biedt tegen per ongeluk in andermans home directory terechtkomen en zaken inzien. Dat is inderdaad geen 100% veiligheid maar daar gaat het niet om; het is gewoon erg nuttig.
Maar probeer dat maar eens aan iemand duidelijk te maken het soort mensen dat alle IT discussies alleen maar wil zien in termen van security.

Ik had een artikel verwacht over encryptie van de home folder / partitie. Dat mag van mij ook wel standaard aan staan. (met de optie om het uit te zetten uiteraard)

Beetje het zelfde probleem als bij Windows en Mac: Het is heel goed voor de beveiliging, maar het is heel slecht voor de reguliere gebruiker wiens computer gecrasht it en hem naar de PC winkel moet brengen. Encryptie is optioneel omdat er hele grote nadelen aan kleven voor de leek.

De 18.4 release notes raadden aan om fscrypt (van ChromeOS/Android) te gebruiken, maar dat gebeurt nog steeds niet standaard. Ik installeer het altijd handmatig.

Graag even "this affects me too" kiezen.

Launchpad: Ubiquity needs support for fscrypt (Ubuntu)

En even thumbs up voor deze:

Github: Ubiquity needs support for fscrypt (Linux Mint)

Het werd tijd.

Standaard dicht ipv open is natuurlijk altijd beter, maar iedereen die dit belangrijk vind wist deze configuratie toch al te vinden.

Dat is zo, in Windows was dit overigens al een tijd zo.

Interessant. Je zou verwachten dat dit 20 jaar geleden al was ingevoerd.

Frappant dat hier nog niet echt vaak naar gekeken is. Naar mijn idee zou dit al in de vorige eeuw omgezet moeten zijn maar dat blijkt toch anders.

Bij de Cisecurity.org benchmarks (https://workbench.cisecurity.org/benchmarks?q=ubuntu) kan ik wel terug kijken tot ubuntu 12, dat daar de standard umask van gebruikers op 077 gezet wordt, dus dat nieuwe bestanden standaard voor de gebruiker alleen zijn (https://workbench.cisecur...660/recommendations/26186). Maar niets over het omzetten van deze open homedirectories.

Sorry, het blijkt dat je een account moet hebben om de benchmarks van cisecurity.org te mogen inzien. Volgens mijn gegevens zijn de benchmarks met het voordeligste (gratis?) account al in te zien. Zelf gebruik ik deze benchmarks vaak om de veilige stand van instellingen op te zoeken, inclusief het waarom.

Dit is nieuws? Linux nieuws bij Tweakers is echt ondermaats. Waarom niet hierover berichten?

Nou zal er vast iemand reageren met dat ik daarover de redactie over moet inlichten. Fair point. Maar mijn ongeloof blijft dat ze dit hier posten als nieuws terwijl er veel beter nieuws is waar tech journalisten zouden van smullen.

Tweakers geeft over het algemeen een meer abstracte overview van de tech sector. De meeste Tweakers hebben een interesse in technologie maar duiken er niet op en heel laag niveau in.

Men hier wil weten wat de specs van de nieuwste iPhone zijn, niet welke bugs er vandaag gefixed zijn in Systemd-networkd.

Toch vind ik dit soort berichten wel verfrissend/leuk tussendoor. De gemiddelde Tweaker weet echt wel wat een home directory is en waar je deze in een Linux distro kan vinden. Dat deze world-readable is was mij niet bekend, ondanks dat ik thuis Ubuntu Server draai voor m'n knutselprojectjes.

Tussen de nieuwe tech releases door vind ik het leuk om zo toch nog iets nieuws te leren.

Ik ben zelf helemaal niet tegen meer Linux nieuws, ik juich het zelfs toe. Al denk ik niet dat de meeste Tweakers hier interesse in hebben.

[Reactie gewijzigd door Omega op 13 januari 2021 23:24]

In mijn beleving was dat ooit anders, maar dan heb je het over meer dan 15 jaar terug. Ach ja, tijden veranderen.

Je hebt wel echt een punt. Tweakers belicht Linux nieuws nauwelijks. Best jammer eigenlijk.

Denk dat het nerd gehalte van dat soort berichten iets te hoog is. Dat is meer interessant voor Slashdot of Osnews ofzo maar hier moet Linux nieuws toch wel in Jip en Janneke taal.

Dit is toch een commerciele site en de meeste bezoekers gebruiken Windows of Mac. Je mag al blij zijn dat dit nieuwswaardig is hier.

Er zijn ook genoeg andere bronnen. Als je hier komt voor Linux nieuws zit je verkeerd.

Een onleesbare home directory is zo onhandig