Best way to mount a windows DFS for multiple users?

Hi,

I've been given a mission, at work, to check if it's possible to setup a RStudio webserver, on Linux.

It's working.

What I have actually is:

  • a portal where you log using your Windows' account
  • a website where you can run R commands through a RStudio webinterface
  • a DFS mounted in a folder

My issue is that my mount doesn't follow the rights of the authenticated user, as I was afraid of.

in my fstab:

//mydomain.local/public/DOCUMENTS /mnt/myfolder.local   cifs credentials=/.samba_credentials,uid=administrator,noperm,rw, 0 0

and I can sudo mount /mnt/myfolder.local/ to access the DOCUMENTS folder on my windows dfs. The issue is that rights don't follow the user.

I'm logged with "Firstname.Lastname@mydomain" on RStudio, I click on file -> save -> move to the mounted DFS, my rights are those of the mounter (administrator).

What would be the best practice for that? A mount per user in their folder, some rights masquerading?

Any help could be useful :)

Posted Apr 20, 2022, 10:48 PM UTC

23
dundir•

First, I gotta ask, have you looked over the EULA for the RStudio you are using and verified that this is allowed within the scope of the license you have. They have re-licensed certain RStudio products so they are no longer AGPL. I'd hate to see you get hit with a copyright strike because of a mixup.

Second is tricky because there are so many variable stacks and factors that the problem domain quickly grows to exponential infinities. Without knowing more about how and the interfaces being used during normal workflow its impossible to narrow that down.

If its something simple for usage like generating or pulling a file, I'd say setup a worker and have a dynamically generated file generated via a web request using PHP or other server side script language, but man that's gonna be a nightmare project until you can nail down your requirements scope and testing. A lot depends on how your users will need to interact or use the server.

Also don't forget, Windows DFS absolutely hates Unix file naming schema. So many issues with cases, special characters, and atime changes resulting in filesystem race conditions. I don't envy you this job.

1
ncphobsOP•

the EULA for the RStudio you are using and verified that this is allowed within the scope of the license you have

https://www.rstudio.com/products/rstudio/#rstudio-server

it is (free version) but I appreciate the (legit) concern.

My question was more on the mount side of the thing. The users are logged through a legit pam and authenticated properly via the browser, with a unix session coming up and a user folder setup into /home/mydomain/username

DFS should be set in UTF8 so names would be ok

some screenshot https://imgur.com/a/NnzXBZW

What I'd like would be :

  • users have access to a dfs

  • When they read, write, modify a file, file is updated with their windows username (which is bound with their unix equivalent through winbind), even through the RStudio Web version

  • it works already on local, but not on a mount -> user:group permissions on a new file are windows' groups' names:

      [email protected]:Domain\ [email protected]
    

I'm trying to figure if I have to add a mount for each user in their user's folder: /home/DOMAIN.LOCAL/user.name/dfs_mount/ or if there's another way to do so, more clean.

1
dundir•

Hmm, well there is a cifs option for multiuser, but you run into this, there's a workaround but it was fairly limited from what I recall when I was looking into it about a year ago.

I've since lost access to my redhat subscription so I can't tell if a better workaround was found.

Edit: There were also some other downsides that are environment dependent, specifically where you may have needed to enable pam_keyinit.so and pam_cifscreds.so, the latter stores the user passwords in the kernel for pamcifs to use as the user logs into the DFS server, if client and server usernames and passwords don't match issues ensue.

That does have the impact of bringing in more potential security policy concerns, that generally need special documenting in SOX audited companies. Hopefully not a dealkiller.

1