Read-only mounten behalve voor root

[dtech]

Ik backup op dit moment een server met een scriptje dat rsync'ed naar een backupschijf.

Nadeel is echter dat de backups nu writeable zijn, waar ik pijnlijk achter kwam doordat een automatisch deface scriptje alle index.php's writable door www-data verving.

Om zulke scenario's te voorkomen wil ik de backups dus write-only maken. Daar kon ik een aantal dingen voor bedenken:

1. Tarren i.p.v. hardlinks
2. chmodden
3. Read-only mounten en in het script unmounten, remounten (rw), unmounten en weer remounten (ro).
4. Schijf enkel beschrijfbaar maken door cron/root

1 is niet echt handig, omdat ik soms losse files nodig heb en geen zin heb om elke keer te untarren. 2 is ook niet handig omdat ik files wil kunnen terugzetten met exact dezelfde chmod-informatie, en niet opeens alles writable of un-writable.
3 is natuurlijk doable, maar is ook niet super-handig, aangezien ik ook wel eens op de backup schijf wil schrijven (oude backups verwijderen bijv.)

Het liefst wil ik de schijf dus zo instellen dat enkel root er naar kan schrijven. Ik kan echter niet goed vinden hoe dat kan met behoud van de goede user/group informatie. Is dat mogelijk of is 3 de enige optie?

[Verwijderd]

Ik zou een user aanmaken waarmee jij niet kan inloggen maar wel met sudo het recht krijgt om te kopiëren.

[Gratzip]

Ja nieuwe gebruiker aanmaken en dan een combinatie van chown en chmod, zoiets zou ik doen.
chown root:root <iets>
chmod u+r <hetzelfde iets>
(uit mijn hoofd)

[swbr]

Zorg dat die backupschijf offsite staat en doe een rsync over ssh.

[Kees]

of zet maak de dir waarin de backups staan van root, en chmod hem naar 700

[Rainmaker]

Niet nodig, je kan aan rsync direct de --chmod optie meegeven, die de permissies van de source overschrijft.

[deadinspace]

Rainmaker schreef op maandag 03 januari 2011 @ 17:00:
Niet nodig, je kan aan rsync direct de --chmod optie meegeven, die de permissies van de source overschrijft.

Dat zou ik afraden; je wil graag de originele permissies op backups. Backups gaan over meer dan alleen de inhoud van files

Ik ga met Kees' advies mee. Eenvoudig maar voldoende.

[Rainmaker]

Eens, maar aan de andere kant wil je de schijf eigenlijk ook ge-umount of read-only hebben na de backup.

Anders kun je nog steeds met een rm -rf / alles om zeep helpen, inclusief je backups.

[dtech]

@Rainmaker
natuurlijk, dat is slechts een speciaal geval van dat backups niet beschrijfbaar moeten zijn

@Kees
Maar dan kunnen de individuele files toch nog steeds aangepast worden? De specifieke map waar de backups in staan staan inderdaad op 770 root:root

@Antaresje
gelijk heb je, maar daar is op dit moment geen mogelijkheid voor (aangezien we geen offsite locatie met voldoende snelheid voor de backups hebben)

[H!GHGuY]

dtech schreef op maandag 03 januari 2011 @ 19:46:
@Kees
Maar dan kunnen de individuele files toch nog steeds aangepast worden? De specifieke map waar de backups in staan staan inderdaad op 770 root:root

tenzij je nog users in group "root" hebt kunnen externe users er niet aan.
Het probleem is echter dat als je hardlinks gebruikt en de originele file is wel accessible dan kan er alsnog vanalles mee gebeuren. Hardlinks zijn geen goed backup mechanisme. (Of begrijp ik dit verkeerd uit je openingspost?)

[CyBeR]

H!GHGuY schreef op dinsdag 04 januari 2011 @ 09:58:
[...]


tenzij je nog users in group "root" hebt kunnen externe users er niet aan.
Het probleem is echter dat als je hardlinks gebruikt en de originele file is wel accessible dan kan er alsnog vanalles mee gebeuren. Hardlinks zijn geen goed backup mechanisme. (Of begrijp ik dit verkeerd uit je openingspost?)

Hardlinks worden hier gebruikt om de backup in 't fs toch incremental te maken.

Met kees, verder.

[dtech]

De backup map is 770 root:root, de files eronder niet. Kunnen mensen dan niet alsnog bij die files?

Inderdaad, 't is een optie van rsync: als de vorige backup een identieke file bevat wordt de file niet gekopiëerd maar wordt er een hardlink naar de file (van de vorige backup) gemaakt. Spaart ruimte terwijl je toch alle files in elke backup hebt. Op het moment dat een file veranderd wordt hij natuurlijk wel gekopieerd i.p.v. gehardlinkt en gewijzigd o.i.d.

[ Voor 13% gewijzigd door dtech op 04-01-2011 12:54 ]

[H!GHGuY]

dtech schreef op dinsdag 04 januari 2011 @ 12:49:
De backup map is 770 root:root, de files eronder niet. Kunnen mensen dan niet alsnog bij die files?

Nee. Zolang anderen geen read/execute rechten hebben op de dir, kunnen ze niet in de backup map.

[CAPSLOCK2000]

Je zou eens kunnen kijken naar SELinux, al voelt dat een beetje als overkill.

Ik zou zelf voor optie 3 kiezen en het voor lief nemen dat ik een extra handeling moet doen voor ik dingen kan deleten, zo vaak zal dat toch niet voorkomen dat je backups handmatig opruimt.
Ik zie die extra handeling (rw mounten) alleen maar als een extra beveiliging.
Ik zou dan wel zorgen dat de boel automatisch weer op ro wordt gezet na een paar uur zodat er geen rampen gebeuren als je zou vergeten om ro weer aan te zetten.

[u_nix_we_all]

Waarom uberhaupt je backups nog (ro) mounten ? Waarom niet alleen mounten als hij nodig is, voor het maken van backups, (en eventueel restoren,) en voor de rest die disk gewoon niet mounten

[CAPSLOCK2000]

TS wil graag zijn backups online hebben zodat hij makkelijk losse files kan terugzetten.

[leuk_he]

Zelf nooit geprobeerd, maar zou je disk quota daar niet voor kunnen misbruiken, zodat gebruikers geen quota meer over hebben , maar root wel?


Meer geeigend is dat je een schijft op een lvm die een snapshot heeft, en dat je voor de gebruiker een RO snapshot mount en voor de root een andere snapshot die not wel writable is.

[ Voor 39% gewijzigd door leuk_he op 06-01-2011 18:06 ]

[dtech]

Bedankt voor alle hulp, en wat Kees zij werkt inderdaad.

Ik wist niet dat je r?x rechten nodig had op alle mappen in de tree dus dan kun je inderdaad niet meer bij de backupfiles als de hoofd-backup map root:root 770 is

@leuk_he
Inderdaad grappig idee, maar volgens mij kan je nog wel files bewerken/verwijderen ook als je over je quota heen bent

@u_nix_we_all
We moeten inderdaad regelmatig bij de backupfiles, omdat er een heleboel leken van de server gebruik maken en dan nog wel eens wat kapot maken (laatst had een admin per ongeluk een mailinglijst verwijdert per ongeluk). Alleen mounten wanneer nodig is natuurlijk wel het veiligst, maar zo werkt het ook