Omdat mijn kennis over lees-, schrijf en andere rechten toch nog wel enigszins tekort schiet vraag ik er hulp bij.
De situatie is dat ik een export optie aan het maken ben voor mijn database. Gebruikers kunnen hun eigen data exporteren naar een csv bestand en dat vervolgens downloaden. Het aanmaken van het csv bestand gebeurt via mysql (een INTO FILE query), het downloaden via een php script. De bestanden staan dus niet in een publiek toegankelijke directory, maar moeten worden ingelezen door php alvorens ze kunnen worden gepusht.
MySQL heeft dus schrijfrechten nodig, php heeft leesrechten nodig en met mijn ftp user zou ik er ook graag bij willen (om in elk geval eventuele oude bestanden of corrupte bestanden weg te halen). Hoe kan ik dit nu instellen? De enige manier die ik voorlopig heb gevonden is 777..... maar dat is natuurlijk niet wat ik wil.
Eindelijk de tijd gevonden om het te testen, maar het werkt nog niet.
Het volledige pad is:
/home/blabla/domains/domain.com/Opad/Exports
In de laatste directory (Exports) staat de group op een speciale group met de apache user en de mysql user (ik heb geen php user, volgens mij draait die onder apache). De rechten staan daar op 770. De rest van de directories staan tenminste op 711, zodat volgens mij elke user in elk geval erin zou moeten kunnen kijken. Echter mysql geeft me nog steeds de foutmelding dat er niet geschreven kan worden naar de bewuste directory. Wat schoort er dus nog aan?
[size=xsmall]Toevoeging op 20/01/2014 11:02:06:[/size]
Nog even wat verder getest. Een Exports directory direct in de root geplaatst om er zeker van te zijn dat tussenliggende directories het probleem niet kunnen vormen. Ook deze Exports directory de group 'export' gegeven (en getest dat de user mysql daar lid van is). Als ik nu de rechten op 770 zet dan kan mysql er niet in schrijven. Als ik de rechten op 007 zet dan kan mysql er wel in schrijven. Logisch het laatste, maar voor mij blijkt hieruit dat het aanmaken van een group blijkbaar geen enkel effect heeft. Ofwel, wat doe ik klaarblijkelijk verkeerd, ofwel, wat is een andere oplossing?
[size=xsmall]Toevoeging op 20/01/2014 11:17:09:[/size]
Als ik mysql de owner van de directory maak dan werkt het wel.... nu alleen nog zien of php dan nog wel het bestand kan lezen...
[size=xsmall]Toevoeging op 20/01/2014 11:50:55:[/size]
mysql export aan de praat gekregen. Enige wat nog ontbrak was dat de user waarmee ik op de mysql server inlog de juiste FILE permissie had binnen de mysql server:
GRANT FILE ON *.* TO 'user'@'localhost';
Volgende probleem nu: php kan het bestand niet zien. Het csv bestand zie ik wel gewoon in de directory staan, maar welke permissies ik er ook aan geef en welke owners, php blijft het bestand niet zien. Iemand daar dan nog een idee over?
[size=xsmall]Toevoeging op 20/01/2014 11:59:23:[/size]
Lag dus aan hetzelfde probleem. De group permissie wordt gewoon genegeerd. Omdat de permissie op 770 stond had php gewoon geen toegang tot de directory. 775 werkt het wel, maar in grote lijnen ben ik dan weer terug bij af, want dat is liever niet wat ik zie.
Dus bedankt SanThe, maar of ik ben ergens iets vergeten, of het helpt simpelweg niet. Andere ideeen om de permissies correct te zetten worden gewaardeerd.
Gebruikers kunnen hun eigen data exporteren naar een csv bestand en dat vervolgens downloaden. Het aanmaken van het csv bestand gebeurt via mysql (een INTO FILE query), het downloaden via een php script. De bestanden staan dus niet in een publiek toegankelijke directory, maar moeten worden ingelezen door php alvorens ze kunnen worden gepusht.
Waarom dan niet PHP ook het CSV-bestand laten maken? Ik heb dat zelf ooit zo opgelost om twee redenen: (a) MySQL draait op een geheel andere, dedicated server en (b) gebruikers kunnen hun eigen CSV-format instellen, met name voor de kolomscheidingstekens en rij-einden.
Omdat ik dat getest heb en het langer duurt en meer geheugen koste.
Overigens kan je via mysql net zo goed de gebruiker het formaat laten instellen dus je tweede voordeel zie ik niet.
Daar heb je een punt. Ik vervang de CSV-bestanden dan ook alleen bij database-updates via een push in een admin, niet pas bij een pull wanneer een client de download start. Zijn er geen updates, dan wordt in PHP direct een download van het bestaande CSV-bestand gestart. Met zo'n "filecache" is het geheel vaak wel weer sneller, ten koste van schijfruimte uiteraard.
In dit geval kan een gebruiker niet ongelimiteerd exports maken. Eens in de zoveel tijd (afhankelijk van zijn contract). Zodra de export gemaakt is bewaar ik die als csv bestand en kan de gebruiker deze gedurende een bepaalde periode zo vaak downloaden als hij wil. Na die periode worden ze weer verwijderd. De gebruiker moet dus 1 keer de export aanmaken en daarna kan hij het downloaden.
