Timeline for NFS allow mv and create
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 6, 2016 at 20:03 | history | edited | Armin | CC BY-SA 3.0 |
added 330 characters in body
|
| Apr 6, 2016 at 19:30 | comment | added | Otheus | In your question, describe the NFS server, what version of NFS you are using ; is it a full Linux host? what distribution? Do you have complete control over the environment, including all the clients? Do you (not) trust root on the clients? etc | |
| Apr 6, 2016 at 18:51 | comment | added | Armin | @Otheus but isn't the setup part of your answer? your answer is basically, share is readonly, wrapper applications for every client. or did i miss something? | |
| Apr 6, 2016 at 18:49 | comment | added | Otheus | OK, first, edit your question to state the additional info you mentioned here, the NFS server setup, and the need to prevent local clients from operating on the server | |
| Apr 6, 2016 at 18:45 | comment | added | Armin |
@Otheus so basically, every user gets an alias to mv etc, that calls scp if the operation is allowed? that would work somewhat... i'll think about it, but that seems to be the most sensible solution. if you make it an answer, i cant mark it...
|
|
| Apr 6, 2016 at 18:41 | comment | added | Otheus |
Yes. so basically, you need to use some program that does not operate on the mountpoint, but with some Application Interface on the server. Mounpotints are read-only. On your NFS server: set up an SSH server for a specific user. That user has access via sudo (NOPASSWD:) to operate the scripts which act on the files in the NFS repository. On clients, wrapper programs like mv operate via ssh to invoke appropriate script.
|
|
| Apr 6, 2016 at 18:03 | comment | added | Armin | @Otheus but if i set the permissions to root:root 744, couldn't a local admin of a client delete the files? | |
| Apr 6, 2016 at 18:00 | comment | added | Otheus |
The only thing you can do, I think, is write a wrapper script protected by sudo, then lock down permissions on NFS volume, such that only root can manipulate files there. Users will interface with sudo rename-script or sudo mv-script
|
|
| Apr 6, 2016 at 17:45 | comment | added | Armin | @MikhailKrutov there are thousands of files on my shares, some are big files like movies, so creating a hash for every time i want to move something is not feasible. | |
| Apr 6, 2016 at 17:34 | comment | added | Mikhail Krutov | @Armin Yep, that's what I've meant - every time something changes, md5 it. Also, unix.stackexchange.com/questions/92013/… | |
| Apr 6, 2016 at 17:32 | comment | added | Armin | @MikhailKrutov this is not acceptable, because i don't see if a file was simply moved on the share. the only way to notice this is to create the hashes for every file anew. | |
| Apr 6, 2016 at 17:22 | comment | added | Mikhail Krutov | Just maintain a list of md5 sums on the share, and if some file goes missing, move it back from a backup. That is not NFS solution, you'll need to write a daemon to monitor it, and it -might- have impact on performance. | |
| Apr 6, 2016 at 16:12 | answer | added | magor | timeline score: 1 | |
| Apr 6, 2016 at 16:08 | history | edited | Armin | CC BY-SA 3.0 |
added examples
|
| Apr 6, 2016 at 16:04 | comment | added | Armin | @Otheus first, they can (via console), and by moving i mean renaming or changing the path, as long as it stays on the disk. i'll add an example | |
| Apr 6, 2016 at 16:03 | comment | added | Otheus | What do you mean by "moving of files"? Renaming? If you can rename a file or move a file, you can effectively edit or delete it. (In fact, in UNIX, moving is often implemented as a kind of remove. ) On a local filesystem in Linux, a file may be marked "immutable", but that means it cannot either be moved or renamed. In theory, Nautilus plugins can achieve the desired effect, assuming users cannot access NFS in any other way. | |
| Apr 6, 2016 at 15:45 | history | asked | Armin | CC BY-SA 3.0 |