Shared network folder, restricted access

Help
NA_WSCB
2013-08-29
2013-08-30
  • NA_WSCB

    NA_WSCB - 2013-08-29

    We have a company network, and we set up a shared folder on a network server where all users' keepass database files are kept. We want to restrict access to the extent that one user cannot see another user's file, as in using Windows Explorer. I have used icacls to set rights on the database (.kdbx) files to allow only the user to have rights, but when a user makes a change to the database, the new, modified file re-inherits the rights of the folder. If I restrict the folder rights, then I get the "not able to save file, save somewhere else" warning. I think it has something to do with the creation of the database.kdbx.tmp file. We also have a generic database file that is used to create a new user's database file through the network login script. So far I can get the user to be able to make changes to his file, but then the file is visible to the other users. This is by allowing "everyone" to have Modify rights within the folder. Can anyone tell me if there is a way to set rights (create but not modify?) to do what we want?

    Thanks.

     
  • wellread1

    wellread1 - 2013-08-30

    KeePass deletes the old encrypted .kdbx file and writes a new one every time the database is saved. Since a file deletion-creation is involved, the newly created .kdbx file will inherit the folder permissions as you observed. You have to design your overall database administration procedures to account for this.

    Note: whether database.kdbx.tmp is created depends on the option Tools>Options>Advanced(tab)>File Input/Output Connections "Use file transaction for writing databases". However it does not alter the overall delete/create sequence in a database save.

    Depending on your actual objective there may be suitable alternate arrangements of databases.

     
    Last edit: wellread1 2013-08-30
  • steelej

    steelej - 2013-08-30

    I have not been able to try it but I think you might experiment with making the folder you are using as the parent folder for the KeePass files (as I think you have already done) and apply the following:

    1. Set the permissions on this folder so it does not inherit permissions from its parent and then add the account "Creator Owner" to the folder and grant this read/write/delete permission.

      • You could also try adding List folder contents.
    2. Add a group for your users and grant "List Folder Contents" to the group.

      • [If the List Folder contents permission above makes the files visible to the individual users this step may not be necessary]
    3. Ensure that the user group does not have read, delete or write access to files in the folder.

    The Creator Owner setting should allow users to create/change/read and delete their files. Other users should not be able to open them although they may be able to see that they exist.

    You may want to add an administrator account or group as well so that an admin could manage files although such a user should always be able to take ownership of the file.

    File permissions always seem to be a case of trial and error. I hope this helps.

     
  • wellread1

    wellread1 - 2013-08-30

    It seems I am mistaken on how "Use file transaction for writing databases" affects the database save routine. The old database does not appear to be deleted when this option is disabled.

    steelej's suggestion to manage permissions using the "Creator Owner" account and assigning ownership of individual databases should be convenient. User accounts/groups can include minimum privileges or none at all. If it is not possible to arrange for users to view their own databases via Windows Explorer, KeePass can still open the database via the File>Open Recent list, a trigger, or via a shortcut with a command line switch (i.e. using any method to pass the path directly to KeePass).

     
    Last edit: wellread1 2013-08-30

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks