as the title suggest, I need to handle the tenant files in a multi-tenant saas app. fairly common scenario I believe and should have been solved by the gurus already.

right now the app is in infancy and does not have many clients. it may become popular, or it may eventually prove to be a total failure.

so by following the rule of keeping it simple and create something only when we need it, I went with a very basic LocalFileStorage application service.

This service takes the file and the tenant ID, and saves everything into a local data dir that looks something like this

// dir structure = /data/{tenant-id}/{file-type}/{file-name}


and I believe the same dir structure can be migrated easily to a cloud like AWS or Google, if someday the need arises.

but there are few design decisions where I am a little bit stuck and need your expert advice.

  • the dir structure hierarchy, is it alright? keeping everything under a tenant ID to make sure all files of a single tenant are always together? I was told by a DDD/micro-service fan that instead of dir-per-user, I should be making the service name (like invoice) to be the top dir and then use tenant Id, (/data/invoices/tenant-3/) because at anytime, contexts have the highest priority to create the boundaries in ddd. question is, does it even matter where and how the files are stored as long as everything is tucked away behind a handler service?

  • the real question is, how to secure the files so that none (including the sys admins) can read or open them, and only the logged in person can get to see and read the actual file. obviously encrypting the files before storing them and then decrypting on the fly when serving the client sounds like the right option but I have a feeling that if I will do it myself, it is gonna bite back. what are the options for such a task in linux based system?

1 Answer 1


What Filesystem are you using?

Are you aware that file-systems have user permissions baked in. The right File-System can for example prevent even the generally powerful admin (except those with unfettered sudo rights) from having access. Even better they have builtin encryption.

Create a user. Give them exclusive access to the directory. Make this user the account under which the service runs.

If you want to make it even more secure, setup one id per tenant, and fork the process per tenant to prevent cross-access.

  • The whole point of the encryption is to protect from those with "unfettered sudo rights": "including the sys admins". Commented Sep 7, 2020 at 6:38
  • Okay, do not give any admin those rights. Not even the right to grant rights. Just make sure you have done it right, because you will effectively brick your box. Alternately you could just encrypt those files, now how are you going to store the keys given they are required on the local machine. Trusted modules won't do, an admin has the time, and access to conduct attacks to extract such certificates. Can't store it in a key store either, they are responsible for setting up the access, and they have the tools to spoof requests. The only solution is for the client to decrypt on their end.
    – Kain0_0
    Commented Sep 7, 2020 at 7:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.