)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"a530151bf2a576817246a4eab8c4a64f767a8f86","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"94c81cf7_5bb9d148","updated":"2023-05-05 15:48:09.000000000","message":"\"Thank you, Goutham, for proposing this spec. It covers almost all of the points we discussed. I have added my comments on what still seems to be missing or problematic. But overall, the mechanism seems good to me.\"","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"265a614cbf6d1d6393e84edfcd1d6692f59360e5","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"69b63136_f4ece097","updated":"2023-05-18 23:54:49.000000000","message":"Sean: I think, with your latest comments, i understand your objection that the service role user\u0027s ID is recorded in the manila database to apply these visibility and deletion restrictions.. \n\nI personally didn\u0027t think this was going to be a problem, but you may be seeing something I am not; i\u0027d be happy to be told the downsides of doing this...","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"8be5ff5141fc904a6fe607f9a8fc4b4f5e76921f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a4039cc5_4566f94d","updated":"2023-05-16 16:22:08.000000000","message":"See inline, I\u0027ve also added Dan Smith for his angle, since he put a lot of work on the recent data leak CVE that I\u0027ve mentioned.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"466905e9c10138b5a829887f93005a55d42f69c9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"b0942294_8dd7a34b","updated":"2023-05-04 17:47:12.000000000","message":"Thank you Haixin. I can make some changes, but, i followed up with some questions on your comments","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"adff7d83e3a1c7cdca8f7d71809679fe7e481a4b","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f1fa01ab_932a4f8e","updated":"2023-06-14 05:44:58.000000000","message":"Thank you all for your comments; latest patch will address some of the concerns raised.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"876f1ec74c0d5e1418a3fea4810caef8f21b843d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"44591a4e_ee2d7542","updated":"2023-05-18 17:03:15.000000000","message":"Thank you very much for your comments Haixin, Rene and Sean.. i\u0027ve responded to them inline; i\u0027ll make some edits requested and post a patch.. we can ofcourse continue conversation on the unresolved aspects.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":30407,"name":"haixin","email":"haixin_haixin@qq.com","username":"haixin"},"change_message_id":"9c706dbb35091aeb28ef77e19542bae9f75e9e41","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"d09bc93b_b3004406","updated":"2023-05-04 03:09:25.000000000","message":"hi, Goutham Pacha Ravi\nthanks for your change.\nhere are some questions about this spec. :)","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":30407,"name":"haixin","email":"haixin_haixin@qq.com","username":"haixin"},"change_message_id":"28c9fefcd4f1403c79b0fa15070d9f60fb76ba78","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"bb98d9d1_1a322b10","updated":"2023-05-05 02:01:52.000000000","message":"thanks for your answer. Goutham Pacha Ravi.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"a0e2af3f6d32dadeff8fc42488e41f64c1899a70","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"96dc214f_9f51c2a3","in_reply_to":"4c66f1cd_3ffb6b83","updated":"2023-06-14 05:48:38.000000000","message":"i see; this is an important call out; is there any identifier that connects the two users that we can rely on? as an option, if a service is restricting a rule, instead of using a user_id, we can just always look for X-Service-Id, validate the \"service\" role, and use that for restriction.. the downside here is that we won\u0027t be able to distinguish a \"nova\" service, from any other service...","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"d0e80318ace0d8dff2662779bce52307f6bbda4a","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"4c66f1cd_3ffb6b83","in_reply_to":"69b63136_f4ece097","updated":"2023-06-06 18:10:15.000000000","message":"there is no assumption that that user remains the same over time.\none of the way sto do password rotation without service downtime is to create a second nova user account, do a rolling update and when all are updated to that delete the old one.\n\nwithout using application credentials there is no way to rotate password without downtime. you have to update the keystone password then update all the configs.\nyou cannot have two passwords fo a user at the same time so  either you use application credential or you use use a second user.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":29632,"name":"Carlos Eduardo","email":"ces.eduardo98@gmail.com","username":"silvacarlos"},"change_message_id":"8f97425120da0ae539791f66b373159e42b469fb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"b2094c4b_6b0b1189","updated":"2023-07-07 21:11:10.000000000","message":"LGTM, thank you Goutham!","commit_id":"10e4c609fea5838f4b7dd128626568e1f0a5a2f1"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"2dbf55b6ddaaf51943f09d8ebd3dda075f012473","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"9dbcfd47_0f2bed98","updated":"2023-07-06 17:25:37.000000000","message":"Thanks for your patience with this; i\u0027ve updated the spec and simplified it quite a bit to use resource locks..","commit_id":"10e4c609fea5838f4b7dd128626568e1f0a5a2f1"},{"author":{"_account_id":30407,"name":"haixin","email":"haixin_haixin@qq.com","username":"haixin"},"change_message_id":"e147bb5d2b99ff8410bba654cb1705425b7ed58f","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"0301c030_7a9333e6","updated":"2023-07-10 02:47:19.000000000","message":"We can continue the discussion in the implementation :)\ni think we can merge it. LGTM.","commit_id":"10e4c609fea5838f4b7dd128626568e1f0a5a2f1"},{"author":{"_account_id":29632,"name":"Carlos Eduardo","email":"ces.eduardo98@gmail.com","username":"silvacarlos"},"change_message_id":"03cc1e76eacec02c2f160e885de1a6c4e0679354","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"f15ffd6e_5d8b4b51","in_reply_to":"b2094c4b_6b0b1189","updated":"2023-07-07 21:11:46.000000000","message":"We can continue the discussion in the implementation :)","commit_id":"10e4c609fea5838f4b7dd128626568e1f0a5a2f1"}],"specs/bobcat/protect-access-rules.rst":[{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"fbf6b1f8b0644afd16298f42ffcc0cfe8e45faf9","unresolved":true,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Prevent Access rules from being viewed or manipulated by non-owners"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Include the URL of your launchpad blueprint:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"95893c59_5d8bb677","line":8,"updated":"2023-05-16 21:52:13.000000000","message":"thinking about this a bit over dinner if i was to write this spec i think i woudl narrow the focus to just the one concept.\nin this case i think the priamry change is the concept that an access rule cold be owned by either a project or a user where as previouslyit was owned by a project.\n\nto enable this i woudl intoduce the concept of a access rule scope or rule owner\nto an access rule as a top level filed.\nthat could be  either  the proejct or the user.\n\na user scoped acess rule would be owned by that user and only visabel to that user\nonly that user could modify list or delte the user owned rule.\n\na projected scoped access rule would owned by the project and visable to all member of that proejct. This is the beahvior we have today and woudl continue to be the default if a user was not specifed when creating the rule.\n\n\nthe db changes would mostly remain the same having an optional user_id filed mappipng a user to a rule where no user means project owned but you would not need ot intoduce the\nrestrict_visablity  metadtata on the access rules\n\nit would be implictly restrited to the ownere be that that project or user.\n\na acess rules that is created with a user_id would be scoped to just that user\nand access rules created without one would be scoped to the project.\n\nresirct_deletaion feels like a seperate usecase that i would put our of scope of this spec personaly.\n\ni think that stil enabled the idea of mapping keystone users to cephx key users.\nbut it does not open the poissblity fo acess_rules that are assocated with a user having restrict_visablity\u003dfalse.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"90215142481b8c9cde0a5465e7729b13e7a0d1e5","unresolved":true,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Prevent Access rules from being viewed or manipulated by non-owners"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Include the URL of your launchpad blueprint:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7fc7be12_ffc5b6aa","line":8,"in_reply_to":"14f1bb14_a8f0ed9f","updated":"2023-05-18 19:20:00.000000000","message":"in nova you cant list or see keyparis belonging ot other user  via the keypair api but you can see the keypair name on a vm someone else created in the same project if that is what you mean\n\nso for manilla you want to be able to se the list fo access rules created for the share \nlike if a vm had a list of keys\n\nbut still do not want to be able to get the access rule if its scoped to a user\nor list them if they are not yoru rules ot project scoped right.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"265a614cbf6d1d6393e84edfcd1d6692f59360e5","unresolved":true,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Prevent Access rules from being viewed or manipulated by non-owners"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Include the URL of your launchpad blueprint:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"c2c16009_ea24be40","line":8,"in_reply_to":"7fc7be12_ffc5b6aa","updated":"2023-05-18 23:54:49.000000000","message":"yes you got me.. clarifying the last bit:\n\n\u003e but still do not want to be able to get the access rule if its scoped to a user\nor list them if they are not yoru rules ot project scoped right.\n\nThe user can only view access rules via `GET /share-access-rules?share_id\u003d{}` or `GET /share-access-rules/{access_rule_id}`. So they can continue to do this; if they are permitted by policy to use the API, they can get a 200 with redacted information as described in the REST API impact","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"876f1ec74c0d5e1418a3fea4810caef8f21b843d","unresolved":true,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Prevent Access rules from being viewed or manipulated by non-owners"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Include the URL of your launchpad blueprint:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"14f1bb14_a8f0ed9f","line":8,"in_reply_to":"95893c59_5d8bb677","updated":"2023-05-18 17:03:15.000000000","message":"Thanks Sean! \n\n\u003e in this case i think the priamry change is the concept that an access rule cold be owned by either a project or a user where as previouslyit was owned by a project.\n\nyes; \"owned\" is a bit confusing though - because the project still \"owns\" these rules in some sense; and the change is that users can restrict project owned access rules to themselves -- somewhat like keypairs in nova. As a project user, I can see keypairs used when creating instances, but I can only view/delete my own keypair. \n\n\n\u003e a user scoped acess rule would be owned by that user and only visabel to that user\n\nmy problem with this is visibility. We\u0027re providing shared file systems, we don\u0027t want to take away the ability to see who all may be using the share - the access rules list provides this view. With restrictions, you may not know who _exactly_ has mounted the share, but atleast you know the user that has a restricted rule on the share. This will be useful if you would like to perform some action on the share: grow/shrink the share, migrate it elsewhere, unmanage it, replicate it, etc and would like to communicate with the users so they\u0027re not surprised by your action.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"2dbf55b6ddaaf51943f09d8ebd3dda075f012473","unresolved":false,"context_lines":[{"line_number":5,"context_line":" http://creativecommons.org/licenses/by/3.0/legalcode"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":8,"context_line":"Prevent Access rules from being viewed or manipulated by non-owners"},{"line_number":9,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":10,"context_line":""},{"line_number":11,"context_line":"Include the URL of your launchpad blueprint:"}],"source_content_type":"text/x-rst","patch_set":1,"id":"0bd6cd3f_bbf9982d","line":8,"in_reply_to":"c2c16009_ea24be40","updated":"2023-07-06 17:25:37.000000000","message":"Done","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6806e8c38aef98b544cc3c7e15dfcfad99203cb4","unresolved":true,"context_lines":[{"line_number":23,"context_line":""},{"line_number":24,"context_line":"When creating an access rule for a share, a user can provide type of access"},{"line_number":25,"context_line":"requested (``access_type``), a client identifier (``access_to``),"},{"line_number":26,"context_line":"the level of access (``access_level``) and metadata. All of this information"},{"line_number":27,"context_line":"is namespaced in a way that anyone that is able to view the share can view"},{"line_number":28,"context_line":"the access rules that are associated with it. Sometimes this may not be"},{"line_number":29,"context_line":"desirable. When a user creates a CephX access rule, they are able to retrieve"},{"line_number":30,"context_line":"the CephX access secret key via Manila, this key is privileged information."},{"line_number":31,"context_line":"Sharing this key among other users of the project would mean that a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ef26b353_c634ae03","line":28,"range":{"start_line":26,"start_character":53,"end_line":28,"end_character":45},"updated":"2023-05-16 19:21:18.000000000","message":"i dont think this remotely true \nhttps://docs.openstack.org/api-ref/shared-file-system/?expanded\u003ddescribe-share-access-rule-detail#share-access-rules-since-api-v2-45\n\nthese access rules are currently resticted to members of the same project.\nhttps://github.com/openstack/manila/blob/master/manila/policies/share_access.py#L42-L70\n\nyou cant access this manilla api without being logged in","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"adff7d83e3a1c7cdca8f7d71809679fe7e481a4b","unresolved":false,"context_lines":[{"line_number":23,"context_line":""},{"line_number":24,"context_line":"When creating an access rule for a share, a user can provide type of access"},{"line_number":25,"context_line":"requested (``access_type``), a client identifier (``access_to``),"},{"line_number":26,"context_line":"the level of access (``access_level``) and metadata. All of this information"},{"line_number":27,"context_line":"is namespaced in a way that anyone that is able to view the share can view"},{"line_number":28,"context_line":"the access rules that are associated with it. Sometimes this may not be"},{"line_number":29,"context_line":"desirable. When a user creates a CephX access rule, they are able to retrieve"},{"line_number":30,"context_line":"the CephX access secret key via Manila, this key is privileged information."},{"line_number":31,"context_line":"Sharing this key among other users of the project would mean that a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"58e91010_551ded96","line":28,"range":{"start_line":26,"start_character":53,"end_line":28,"end_character":45},"in_reply_to":"025f9089_5c706c23","updated":"2023-06-14 05:44:58.000000000","message":"Done","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"90215142481b8c9cde0a5465e7729b13e7a0d1e5","unresolved":true,"context_lines":[{"line_number":23,"context_line":""},{"line_number":24,"context_line":"When creating an access rule for a share, a user can provide type of access"},{"line_number":25,"context_line":"requested (``access_type``), a client identifier (``access_to``),"},{"line_number":26,"context_line":"the level of access (``access_level``) and metadata. All of this information"},{"line_number":27,"context_line":"is namespaced in a way that anyone that is able to view the share can view"},{"line_number":28,"context_line":"the access rules that are associated with it. Sometimes this may not be"},{"line_number":29,"context_line":"desirable. When a user creates a CephX access rule, they are able to retrieve"},{"line_number":30,"context_line":"the CephX access secret key via Manila, this key is privileged information."},{"line_number":31,"context_line":"Sharing this key among other users of the project would mean that a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"025f9089_5c706c23","line":28,"range":{"start_line":26,"start_character":53,"end_line":28,"end_character":45},"in_reply_to":"8ba70703_cef0407b","updated":"2023-05-18 19:20:00.000000000","message":"ack ya i can see how the current system woudl be problematic with public share\n\naltough for public shares to be useful would you not need to provide access to the acess rule so people could conenct to the share?","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"876f1ec74c0d5e1418a3fea4810caef8f21b843d","unresolved":true,"context_lines":[{"line_number":23,"context_line":""},{"line_number":24,"context_line":"When creating an access rule for a share, a user can provide type of access"},{"line_number":25,"context_line":"requested (``access_type``), a client identifier (``access_to``),"},{"line_number":26,"context_line":"the level of access (``access_level``) and metadata. All of this information"},{"line_number":27,"context_line":"is namespaced in a way that anyone that is able to view the share can view"},{"line_number":28,"context_line":"the access rules that are associated with it. Sometimes this may not be"},{"line_number":29,"context_line":"desirable. When a user creates a CephX access rule, they are able to retrieve"},{"line_number":30,"context_line":"the CephX access secret key via Manila, this key is privileged information."},{"line_number":31,"context_line":"Sharing this key among other users of the project would mean that a"}],"source_content_type":"text/x-rst","patch_set":1,"id":"8ba70703_cef0407b","line":28,"range":{"start_line":26,"start_character":53,"end_line":28,"end_character":45},"in_reply_to":"ef26b353_c634ae03","updated":"2023-05-18 17:03:15.000000000","message":"I can see how this can be read now that you have these pointers :) \n\nI\u0027ll rewrite this to scope out exactly who can view access rules of a share by default. The policy allows \"project\" readers (and inherently, \"members\") and \"admin\" can view access rules; but, manila has a concept of \"public\" shares*. These are visible across tenants, and any logged in user can see access rules of a public share. \n\n[*] Creation of public shares are prevented by virtue of default RBAC to only \"admin\" users.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6806e8c38aef98b544cc3c7e15dfcfad99203cb4","unresolved":true,"context_lines":[{"line_number":27,"context_line":"is namespaced in a way that anyone that is able to view the share can view"},{"line_number":28,"context_line":"the access rules that are associated with it. Sometimes this may not be"},{"line_number":29,"context_line":"desirable. When a user creates a CephX access rule, they are able to retrieve"},{"line_number":30,"context_line":"the CephX access secret key via Manila, this key is privileged information."},{"line_number":31,"context_line":"Sharing this key among other users of the project would mean that a"},{"line_number":32,"context_line":"CephX user key is visible and usable by multiple OpenStack project users. If"},{"line_number":33,"context_line":"the goal was to allow only a subset of the OpenStack users to access the"},{"line_number":34,"context_line":"share, the purpose is defeated with this level of visibility. The same"},{"line_number":35,"context_line":"applies if individual CephX users had to have different access levels"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b14a94fc_6d646b21","line":32,"range":{"start_line":30,"start_character":40,"end_line":32,"end_character":73},"updated":"2023-05-16 19:21:18.000000000","message":"i would disagee with this statement\n\nthe cephx key is private not privileged and its owned by the project not the user.\nso it approprate for it to be shared by other user in the same project\n\nalso you are expect ot be able to retirve the cephx key so that you can mount the cephfs file system directly in a nova vm  ironic baremental host or external host.\n\nwhlie manillay support rexporting ceph strovate provisioned as ciner voluesm using nfs or iscsi you are not required to do that so it perfectly valid to create a manial cephfs share and take the cephfs key and use that to mount he cephfs share directly in a client.\n\nthis is valid both for the standalone manilla use case and when usign maniall with nvoa.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"90215142481b8c9cde0a5465e7729b13e7a0d1e5","unresolved":true,"context_lines":[{"line_number":27,"context_line":"is namespaced in a way that anyone that is able to view the share can view"},{"line_number":28,"context_line":"the access rules that are associated with it. Sometimes this may not be"},{"line_number":29,"context_line":"desirable. When a user creates a CephX access rule, they are able to retrieve"},{"line_number":30,"context_line":"the CephX access secret key via Manila, this key is privileged information."},{"line_number":31,"context_line":"Sharing this key among other users of the project would mean that a"},{"line_number":32,"context_line":"CephX user key is visible and usable by multiple OpenStack project users. If"},{"line_number":33,"context_line":"the goal was to allow only a subset of the OpenStack users to access the"},{"line_number":34,"context_line":"share, the purpose is defeated with this level of visibility. The same"},{"line_number":35,"context_line":"applies if individual CephX users had to have different access levels"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2ffa4b5b_b540027d","line":32,"range":{"start_line":30,"start_character":40,"end_line":32,"end_character":73},"in_reply_to":"269568d5_3e36e9fa","updated":"2023-05-18 19:20:00.000000000","message":"right but enabling that woudl be another feature on top of this right.\n\nif you have the ability to create user scsoped/restirct acess rule you could then add a feature to provision a new cephx user for that access rules or map it in some way to the keystone user.\n\nso that woudl be a sperate new feature right?","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"adff7d83e3a1c7cdca8f7d71809679fe7e481a4b","unresolved":false,"context_lines":[{"line_number":27,"context_line":"is namespaced in a way that anyone that is able to view the share can view"},{"line_number":28,"context_line":"the access rules that are associated with it. Sometimes this may not be"},{"line_number":29,"context_line":"desirable. When a user creates a CephX access rule, they are able to retrieve"},{"line_number":30,"context_line":"the CephX access secret key via Manila, this key is privileged information."},{"line_number":31,"context_line":"Sharing this key among other users of the project would mean that a"},{"line_number":32,"context_line":"CephX user key is visible and usable by multiple OpenStack project users. If"},{"line_number":33,"context_line":"the goal was to allow only a subset of the OpenStack users to access the"},{"line_number":34,"context_line":"share, the purpose is defeated with this level of visibility. The same"},{"line_number":35,"context_line":"applies if individual CephX users had to have different access levels"}],"source_content_type":"text/x-rst","patch_set":1,"id":"63a6dc17_d780dbea","line":32,"range":{"start_line":30,"start_character":40,"end_line":32,"end_character":73},"in_reply_to":"2ffa4b5b_b540027d","updated":"2023-06-14 05:44:58.000000000","message":"if the share is namespaced within the project, access rules should be too... hiding the access rules may be undesirable imho to the concept that, the \"owner\" of the share should know if there are accessors, even if they don\u0027t know who exactly (the eventual client\u0027s identity) may be accessing it. This will prevent the owner from accidentally deleting the share or performing operations that may upset a user of the share.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"876f1ec74c0d5e1418a3fea4810caef8f21b843d","unresolved":true,"context_lines":[{"line_number":27,"context_line":"is namespaced in a way that anyone that is able to view the share can view"},{"line_number":28,"context_line":"the access rules that are associated with it. Sometimes this may not be"},{"line_number":29,"context_line":"desirable. When a user creates a CephX access rule, they are able to retrieve"},{"line_number":30,"context_line":"the CephX access secret key via Manila, this key is privileged information."},{"line_number":31,"context_line":"Sharing this key among other users of the project would mean that a"},{"line_number":32,"context_line":"CephX user key is visible and usable by multiple OpenStack project users. If"},{"line_number":33,"context_line":"the goal was to allow only a subset of the OpenStack users to access the"},{"line_number":34,"context_line":"share, the purpose is defeated with this level of visibility. The same"},{"line_number":35,"context_line":"applies if individual CephX users had to have different access levels"}],"source_content_type":"text/x-rst","patch_set":1,"id":"269568d5_3e36e9fa","line":32,"range":{"start_line":30,"start_character":40,"end_line":32,"end_character":73},"in_reply_to":"b14a94fc_6d646b21","updated":"2023-05-18 17:03:15.000000000","message":"i don\u0027t disagree with the implementation; it\u0027s super useful self-service wise. was trying to convey that not all OpenStack deployers like this behavior. If the intent is to allow each OpenStack user map to a cephx user, the current design fails to prevent sharing of this private information.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6806e8c38aef98b544cc3c7e15dfcfad99203cb4","unresolved":true,"context_lines":[{"line_number":35,"context_line":"applies if individual CephX users had to have different access levels"},{"line_number":36,"context_line":"(\"read-only\" vs \"read-write\"); since the CephX users (``access_to``) and"},{"line_number":37,"context_line":"CephX access secret keys (``access_key``) are easily available, nothing"},{"line_number":38,"context_line":"prevents unauthorized access amongst project users."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"In case of NFS with IP access control, users may not want to leak the"},{"line_number":41,"context_line":"IP address of the client for security reasons, even amongst other users of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d764053a_f103dd81","line":38,"updated":"2023-05-16 19:21:18.000000000","message":"is this the spec that came out of the nova manilalla ptg cross project session  because that was not the goal of the feature we ask for in the ptg.\n\nthe feature we asked for in the ptg was a way to lock shares and expots so that they cant be deleted while the share is atteched to a vm.\n\nthis spec seems to be adressing a differnet usescase. im not sure this will help use move the nova share attachment feature forward based on the probelm statemnet.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"90215142481b8c9cde0a5465e7729b13e7a0d1e5","unresolved":false,"context_lines":[{"line_number":35,"context_line":"applies if individual CephX users had to have different access levels"},{"line_number":36,"context_line":"(\"read-only\" vs \"read-write\"); since the CephX users (``access_to``) and"},{"line_number":37,"context_line":"CephX access secret keys (``access_key``) are easily available, nothing"},{"line_number":38,"context_line":"prevents unauthorized access amongst project users."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"In case of NFS with IP access control, users may not want to leak the"},{"line_number":41,"context_line":"IP address of the client for security reasons, even amongst other users of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"fa44dc8e_ae6e228d","line":38,"in_reply_to":"79bf7798_b4193c15","updated":"2023-05-18 19:20:00.000000000","message":"yes i was","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"876f1ec74c0d5e1418a3fea4810caef8f21b843d","unresolved":true,"context_lines":[{"line_number":35,"context_line":"applies if individual CephX users had to have different access levels"},{"line_number":36,"context_line":"(\"read-only\" vs \"read-write\"); since the CephX users (``access_to``) and"},{"line_number":37,"context_line":"CephX access secret keys (``access_key``) are easily available, nothing"},{"line_number":38,"context_line":"prevents unauthorized access amongst project users."},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"In case of NFS with IP access control, users may not want to leak the"},{"line_number":41,"context_line":"IP address of the client for security reasons, even amongst other users of"}],"source_content_type":"text/x-rst","patch_set":1,"id":"79bf7798_b4193c15","line":38,"in_reply_to":"d764053a_f103dd81","updated":"2023-05-18 17:03:15.000000000","message":"No, this specific concern wasn\u0027t discussed at the PTG - it was a concern that came up later in the #openstack-nova channel iirc. I think you\u0027re referring to: https://review.opendev.org/c/openstack/manila-specs/+/881894","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6806e8c38aef98b544cc3c7e15dfcfad99203cb4","unresolved":true,"context_lines":[{"line_number":49,"context_line":"provide some other users of the project with read-only access to the share."},{"line_number":50,"context_line":"They want to prevent these other users from viewing or manipulating cephx"},{"line_number":51,"context_line":"access keys and access secrets. These would then be conveyed out of band to"},{"line_number":52,"context_line":"the other users."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The OpenStack Compute service (Nova) creates an access rule to mount the share"},{"line_number":55,"context_line":"on a compute host and make it available to a virtual machine via VirtIOFS."}],"source_content_type":"text/x-rst","patch_set":1,"id":"109e479e_64fdff69","line":52,"updated":"2023-05-16 19:21:18.000000000","message":"this feels liek you ar changing the ownwership of the acces rules form project owned to user owned which is think is not a good idea in general.\n\nit may be a vaild usecause for mainla but it is not somethign that i think is useful or desirable for nova to use.\n\nvms are owned by project not users and we done want to get into a situration where we cant delete an attachment for a vm as a didfernt user in the same proejct via the nova api because it has been creted by a diffent user.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"876f1ec74c0d5e1418a3fea4810caef8f21b843d","unresolved":true,"context_lines":[{"line_number":49,"context_line":"provide some other users of the project with read-only access to the share."},{"line_number":50,"context_line":"They want to prevent these other users from viewing or manipulating cephx"},{"line_number":51,"context_line":"access keys and access secrets. These would then be conveyed out of band to"},{"line_number":52,"context_line":"the other users."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The OpenStack Compute service (Nova) creates an access rule to mount the share"},{"line_number":55,"context_line":"on a compute host and make it available to a virtual machine via VirtIOFS."}],"source_content_type":"text/x-rst","patch_set":1,"id":"dc07c97e_69d2fd17","line":52,"in_reply_to":"109e479e_64fdff69","updated":"2023-05-18 17:03:15.000000000","message":"I\u0027ll clarify that if Nova sends the X-Service-Token, the restrictions are created in favor of the service user. So only that service user (or the admin) can bypass these restrictions","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"adff7d83e3a1c7cdca8f7d71809679fe7e481a4b","unresolved":true,"context_lines":[{"line_number":49,"context_line":"provide some other users of the project with read-only access to the share."},{"line_number":50,"context_line":"They want to prevent these other users from viewing or manipulating cephx"},{"line_number":51,"context_line":"access keys and access secrets. These would then be conveyed out of band to"},{"line_number":52,"context_line":"the other users."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The OpenStack Compute service (Nova) creates an access rule to mount the share"},{"line_number":55,"context_line":"on a compute host and make it available to a virtual machine via VirtIOFS."}],"source_content_type":"text/x-rst","patch_set":1,"id":"9cc98b88_103e484f","line":52,"in_reply_to":"559b83b1_3d7635f8","updated":"2023-06-14 05:44:58.000000000","message":"I\u0027ll think on this some more; it\u0027ll be done in code, but i agree with the use of the X-Service-Token interaction from Nova...","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"2dbf55b6ddaaf51943f09d8ebd3dda075f012473","unresolved":false,"context_lines":[{"line_number":49,"context_line":"provide some other users of the project with read-only access to the share."},{"line_number":50,"context_line":"They want to prevent these other users from viewing or manipulating cephx"},{"line_number":51,"context_line":"access keys and access secrets. These would then be conveyed out of band to"},{"line_number":52,"context_line":"the other users."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The OpenStack Compute service (Nova) creates an access rule to mount the share"},{"line_number":55,"context_line":"on a compute host and make it available to a virtual machine via VirtIOFS."}],"source_content_type":"text/x-rst","patch_set":1,"id":"d75e415c_986282f9","line":52,"in_reply_to":"9cc98b88_103e484f","updated":"2023-07-06 17:25:37.000000000","message":"Done","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"90215142481b8c9cde0a5465e7729b13e7a0d1e5","unresolved":true,"context_lines":[{"line_number":49,"context_line":"provide some other users of the project with read-only access to the share."},{"line_number":50,"context_line":"They want to prevent these other users from viewing or manipulating cephx"},{"line_number":51,"context_line":"access keys and access secrets. These would then be conveyed out of band to"},{"line_number":52,"context_line":"the other users."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The OpenStack Compute service (Nova) creates an access rule to mount the share"},{"line_number":55,"context_line":"on a compute host and make it available to a virtual machine via VirtIOFS."}],"source_content_type":"text/x-rst","patch_set":1,"id":"559b83b1_3d7635f8","line":52,"in_reply_to":"dc07c97e_69d2fd17","updated":"2023-05-18 19:20:00.000000000","message":"ok so the policy rule\nwould be something like \nhttps://github.com/openstack/nova/blob/master/nova/policies/lock_server.py#L49-L63\n\n\n   policy.DocumentedRuleDefault(\n        name\u003dPOLICY_ROOT % \u0027acess_rule:delete_restricted_acess_rule\u0027,\n        check_str\u003dbase.ADMIN_OR_SERVICE,\n        description\u003d\"\"\"delete the access_rule, regardless of if deleteion is resticted.\"\"\",\n        operations\u003d[\n            {\n                \u0027path\u0027: \u0027/share-access-rules/{share_access_id}\u0027,\n                \u0027method\u0027: \u0027DELETE\u0027\n            }\n        ],\n        scope_types\u003d[\u0027project\u0027]\n    ),\n    \nso even if the user restricted the removal of the access_rule used to attach the share to the vm nova can still remove that rule if a diffent user in the same proejct asked for the share to be detached.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"6806e8c38aef98b544cc3c7e15dfcfad99203cb4","unresolved":true,"context_lines":[{"line_number":55,"context_line":"on a compute host and make it available to a virtual machine via VirtIOFS."},{"line_number":56,"context_line":"It expects that the access rule data (``access_to`` and ``access_key``) are"},{"line_number":57,"context_line":"not visible to other users. `[1]`_"},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Nova would also like to prevent users from deleting an access rule that was"},{"line_number":60,"context_line":"created since it would hard mount the share to the compute host."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"f0b39eab_d9d8afec","line":58,"updated":"2023-05-16 19:21:18.000000000","message":"we would be cureateding it with the end useers keysotn token not as a nova user\nand we need to ensure that if User A in project X cretes the vm and adds the attachemtn that user B in project X can detach the share form the vm.\n\nnova should not need to exclualte privalge to make that work iderally but making this own byt he nova user or similar.\n\nim going to read the rest of the spec but form the problem description and use cases i dont think this is the right direction to take for this feature.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"90215142481b8c9cde0a5465e7729b13e7a0d1e5","unresolved":true,"context_lines":[{"line_number":55,"context_line":"on a compute host and make it available to a virtual machine via VirtIOFS."},{"line_number":56,"context_line":"It expects that the access rule data (``access_to`` and ``access_key``) are"},{"line_number":57,"context_line":"not visible to other users. `[1]`_"},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Nova would also like to prevent users from deleting an access rule that was"},{"line_number":60,"context_line":"created since it would hard mount the share to the compute host."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"510cfc02_dc90bdcd","line":58,"in_reply_to":"29446595_d33c24db","updated":"2023-05-18 19:20:00.000000000","message":"right so this is the bit im not sure i like\n\ni dont think we want to use nova\u0027s own user_id rather than the openstack user that\u0027s requesting the virtiofs mount.\n\ni would want ot see otehr form the nova core team agree to this.\n\nbut i dont like the idea of nova owning anything in any other porject.\n\nyou can allow a request to do thing based on the presence of the service role\nbut the havign resouce owned by nova woudl be a first and im not sure that its a good thing.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"adff7d83e3a1c7cdca8f7d71809679fe7e481a4b","unresolved":true,"context_lines":[{"line_number":55,"context_line":"on a compute host and make it available to a virtual machine via VirtIOFS."},{"line_number":56,"context_line":"It expects that the access rule data (``access_to`` and ``access_key``) are"},{"line_number":57,"context_line":"not visible to other users. `[1]`_"},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Nova would also like to prevent users from deleting an access rule that was"},{"line_number":60,"context_line":"created since it would hard mount the share to the compute host."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"b0cbeffe_84107bad","line":58,"in_reply_to":"510cfc02_dc90bdcd","updated":"2023-06-14 05:44:58.000000000","message":"++ Point noted; i\u0027m hoping to dig on this a bit during the PTG. I or other reviewers will note the discussions back on this spec","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"2dbf55b6ddaaf51943f09d8ebd3dda075f012473","unresolved":false,"context_lines":[{"line_number":55,"context_line":"on a compute host and make it available to a virtual machine via VirtIOFS."},{"line_number":56,"context_line":"It expects that the access rule data (``access_to`` and ``access_key``) are"},{"line_number":57,"context_line":"not visible to other users. `[1]`_"},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Nova would also like to prevent users from deleting an access rule that was"},{"line_number":60,"context_line":"created since it would hard mount the share to the compute host."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"926bc5a1_116e522d","line":58,"in_reply_to":"b0cbeffe_84107bad","updated":"2023-07-06 17:25:37.000000000","message":"Done","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"876f1ec74c0d5e1418a3fea4810caef8f21b843d","unresolved":true,"context_lines":[{"line_number":55,"context_line":"on a compute host and make it available to a virtual machine via VirtIOFS."},{"line_number":56,"context_line":"It expects that the access rule data (``access_to`` and ``access_key``) are"},{"line_number":57,"context_line":"not visible to other users. `[1]`_"},{"line_number":58,"context_line":""},{"line_number":59,"context_line":"Nova would also like to prevent users from deleting an access rule that was"},{"line_number":60,"context_line":"created since it would hard mount the share to the compute host."},{"line_number":61,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"29446595_d33c24db","line":58,"in_reply_to":"f0b39eab_d9d8afec","updated":"2023-05-18 17:03:15.000000000","message":"I am hoping Nova will be using \"X-Service-Token\" (that manila will validate belongs to a valid \"service\" user -- i.e., has whatever roles are allowed for that sort of user via configuration). Presence of this token will indicate that the restrictions will use nova\u0027s own user_id rather than the openstack user that\u0027s requesting the virtiofs mount.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":8864,"name":"Artom Lifshitz","email":"notartom@gmail.com","username":"artom"},"change_message_id":"8be5ff5141fc904a6fe607f9a8fc4b4f5e76921f","unresolved":true,"context_lines":[{"line_number":67,"context_line":"restrict the deletion of the access rule. This will be facilitated through"},{"line_number":68,"context_line":"access rule metadata through reserved metadata keys: ``restrict_visibility``"},{"line_number":69,"context_line":"and ``restrict_deletion``. These metadata keys can be updated after creation"},{"line_number":70,"context_line":"by the user that created the rule or by a user with \"admin\" role."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"The ability to restrict deletion will have an important caveat. While the"},{"line_number":73,"context_line":"deletion of the access rule is restricted, this will not prevent the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"b90ff5a7_77a978fe","line":70,"updated":"2023-05-16 16:22:08.000000000","message":"I wonder if we should make use of the newly-mandatory service token that we got as a fix for [1]. We\u0027re now guaranteed that Nova will always send a service token to Manila when creating an access rule.\n\nCan Manila be made smart enough to understand that when a service token is received with restrict_visibility\u003dTrue and restrict_deletion\u003dTrue, that restriction should _also_ apply to the user whose token is in the request?\n\nIOW, even if making the request on behalf of a user, when it\u0027s Nova making the request, only Nova should have visibility and deletion rights.\n\n[1] https://bugs.launchpad.net/nova/+bug/2004555","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"adff7d83e3a1c7cdca8f7d71809679fe7e481a4b","unresolved":false,"context_lines":[{"line_number":67,"context_line":"restrict the deletion of the access rule. This will be facilitated through"},{"line_number":68,"context_line":"access rule metadata through reserved metadata keys: ``restrict_visibility``"},{"line_number":69,"context_line":"and ``restrict_deletion``. These metadata keys can be updated after creation"},{"line_number":70,"context_line":"by the user that created the rule or by a user with \"admin\" role."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"The ability to restrict deletion will have an important caveat. While the"},{"line_number":73,"context_line":"deletion of the access rule is restricted, this will not prevent the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"22d88b94_dd8d5eff","line":70,"in_reply_to":"2214ea27_ad03a696","updated":"2023-06-14 05:44:58.000000000","message":"Done","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"876f1ec74c0d5e1418a3fea4810caef8f21b843d","unresolved":true,"context_lines":[{"line_number":67,"context_line":"restrict the deletion of the access rule. This will be facilitated through"},{"line_number":68,"context_line":"access rule metadata through reserved metadata keys: ``restrict_visibility``"},{"line_number":69,"context_line":"and ``restrict_deletion``. These metadata keys can be updated after creation"},{"line_number":70,"context_line":"by the user that created the rule or by a user with \"admin\" role."},{"line_number":71,"context_line":""},{"line_number":72,"context_line":"The ability to restrict deletion will have an important caveat. While the"},{"line_number":73,"context_line":"deletion of the access rule is restricted, this will not prevent the"}],"source_content_type":"text/x-rst","patch_set":1,"id":"2214ea27_ad03a696","line":70,"in_reply_to":"b90ff5a7_77a978fe","updated":"2023-05-18 17:03:15.000000000","message":"Totally; thanks for the context and the link. I\u0027ll improve this to call out that when X-Service-Token is provided, we\u0027d permit only the service token user (or admin)","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"a530151bf2a576817246a4eab8c4a64f767a8f86","unresolved":true,"context_lines":[{"line_number":73,"context_line":"deletion of the access rule is restricted, this will not prevent the"},{"line_number":74,"context_line":"deletion of the share. To prevent deletion of shares, resource locks `[2]`_"},{"line_number":75,"context_line":"can be used."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Alternatives"},{"line_number":78,"context_line":"------------"},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"a0680d69_5a74f9a5","line":76,"updated":"2023-05-05 15:48:09.000000000","message":"To prevent inconsistencies, we should consider implementing a mechanism that prevents shares from being created without a lock while access rules are created with the restrict_deletion option.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"adff7d83e3a1c7cdca8f7d71809679fe7e481a4b","unresolved":false,"context_lines":[{"line_number":73,"context_line":"deletion of the access rule is restricted, this will not prevent the"},{"line_number":74,"context_line":"deletion of the share. To prevent deletion of shares, resource locks `[2]`_"},{"line_number":75,"context_line":"can be used."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Alternatives"},{"line_number":78,"context_line":"------------"},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"90d6b795_32b409ae","line":76,"in_reply_to":"9df68e0a_3161a2d1","updated":"2023-06-14 05:44:58.000000000","message":"Done","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"876f1ec74c0d5e1418a3fea4810caef8f21b843d","unresolved":true,"context_lines":[{"line_number":73,"context_line":"deletion of the access rule is restricted, this will not prevent the"},{"line_number":74,"context_line":"deletion of the share. To prevent deletion of shares, resource locks `[2]`_"},{"line_number":75,"context_line":"can be used."},{"line_number":76,"context_line":""},{"line_number":77,"context_line":"Alternatives"},{"line_number":78,"context_line":"------------"},{"line_number":79,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"9df68e0a_3161a2d1","line":76,"in_reply_to":"a0680d69_5a74f9a5","updated":"2023-05-18 17:03:15.000000000","message":"Hmm, that\u0027d be a bit hard to implement; since access rules can only be applied after a share reaches an \"available\" state..","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"fbf6b1f8b0644afd16298f42ffcc0cfe8e45faf9","unresolved":true,"context_lines":[{"line_number":77,"context_line":"Alternatives"},{"line_number":78,"context_line":"------------"},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"Since we need access rule protections between users of the same project, we"},{"line_number":81,"context_line":"don\u0027t have many approaches but to imprint the user\u0027s identity into the"},{"line_number":82,"context_line":"access rule. This feature can be limited to \"admin\" and \"service\" users only."},{"line_number":83,"context_line":"It\u0027d be easier to implement the visibility and manipulation restrictions"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ba22cc9b_1e65d514","line":80,"updated":"2023-05-16 21:52:13.000000000","message":"we do not need access rule prodtion between user in the same project for any nova related uses case i woudl suggess makeign that a spereat spec form the nova usecase because the nova uses case is all about project owned resouces. The vm and the share are boot project owned, nothing shoudl be user owned in the context of attacing a share to a nova server.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"adff7d83e3a1c7cdca8f7d71809679fe7e481a4b","unresolved":true,"context_lines":[{"line_number":77,"context_line":"Alternatives"},{"line_number":78,"context_line":"------------"},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"Since we need access rule protections between users of the same project, we"},{"line_number":81,"context_line":"don\u0027t have many approaches but to imprint the user\u0027s identity into the"},{"line_number":82,"context_line":"access rule. This feature can be limited to \"admin\" and \"service\" users only."},{"line_number":83,"context_line":"It\u0027d be easier to implement the visibility and manipulation restrictions"}],"source_content_type":"text/x-rst","patch_set":1,"id":"90f0388a_462aff51","line":80,"in_reply_to":"04e324ff_c3826541","updated":"2023-06-14 05:44:58.000000000","message":"Yes, 3 isn\u0027t the same... but, there\u0027s one use for this as i mentioned in a comment above.. \n\nAssume a user\u0027s share has a bunch of access rules, user may not be able to see the client identifiers (or access secrets) in some of them. however, there is still value in seeing that these rules exist, because that\u0027s one way of knowing that a share is being used.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"90215142481b8c9cde0a5465e7729b13e7a0d1e5","unresolved":true,"context_lines":[{"line_number":77,"context_line":"Alternatives"},{"line_number":78,"context_line":"------------"},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"Since we need access rule protections between users of the same project, we"},{"line_number":81,"context_line":"don\u0027t have many approaches but to imprint the user\u0027s identity into the"},{"line_number":82,"context_line":"access rule. This feature can be limited to \"admin\" and \"service\" users only."},{"line_number":83,"context_line":"It\u0027d be easier to implement the visibility and manipulation restrictions"}],"source_content_type":"text/x-rst","patch_set":1,"id":"04e324ff_c3826541","line":80,"in_reply_to":"4cbe765e_30c1ccde","updated":"2023-05-18 19:20:00.000000000","message":"in regards to cinder\n\n4 was incorrect untill last week. \n\nit is now true after the cve https://bugs.launchpad.net/nova/+bug/2004555 was fixed by breaking the api contract and stanalone cinder workflow.\n\nhttps://docs.openstack.org/api-ref/block-storage/v3/?expanded\u003ddelete-attachment-detail#delete-attachment\n\n\n\"\"\"\nFor security reasons (see bug #2004555) the Block Storage API rejects REST API calls manually made from users with a 409 status code if there is a Nova instance currently using the attachment, which happens when all the following conditions are met:\n    Attachment has an instance uuid\n    VM exists in Nova\n    Instance has the volume attached\n    Attached volume in instance is using the attachment\n\"\"\"\n\nnow user can condtionlly delete attachments if used for standlone usecases.\n\ntransfering it to virtiofs\n\n3 is not equivalent between teh two.\n\nin cinder the attachment is owned by the porject and was create with the users token.\n\nThe fact the attachment is assocated with a vm is tracted by the fact we set instance_uuid in the attachment when its created.\n\nwhich we do not have in the case of the access_rule\n\nthe corralary woudl be if we added a consume_uuid or instance_uuid field to the accesss_rule and required the service role to set that.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"2dbf55b6ddaaf51943f09d8ebd3dda075f012473","unresolved":false,"context_lines":[{"line_number":77,"context_line":"Alternatives"},{"line_number":78,"context_line":"------------"},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"Since we need access rule protections between users of the same project, we"},{"line_number":81,"context_line":"don\u0027t have many approaches but to imprint the user\u0027s identity into the"},{"line_number":82,"context_line":"access rule. This feature can be limited to \"admin\" and \"service\" users only."},{"line_number":83,"context_line":"It\u0027d be easier to implement the visibility and manipulation restrictions"}],"source_content_type":"text/x-rst","patch_set":1,"id":"ede2159e_53fdd59a","line":80,"in_reply_to":"90f0388a_462aff51","updated":"2023-07-06 17:25:37.000000000","message":"Done","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"c360cbd9cd413ac8fce92655858fe0dae0efac52","unresolved":true,"context_lines":[{"line_number":77,"context_line":"Alternatives"},{"line_number":78,"context_line":"------------"},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"Since we need access rule protections between users of the same project, we"},{"line_number":81,"context_line":"don\u0027t have many approaches but to imprint the user\u0027s identity into the"},{"line_number":82,"context_line":"access rule. This feature can be limited to \"admin\" and \"service\" users only."},{"line_number":83,"context_line":"It\u0027d be easier to implement the visibility and manipulation restrictions"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f413dc5a_93d7c69b","line":80,"in_reply_to":"ba22cc9b_1e65d514","updated":"2023-05-16 21:53:52.000000000","message":"just to be clear im suggesting coverign the nova use cases in a different spec\nsince i dont think the underlying mechiam here woudl be reusabel for that uses case so its not really an alternitive.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"876f1ec74c0d5e1418a3fea4810caef8f21b843d","unresolved":true,"context_lines":[{"line_number":77,"context_line":"Alternatives"},{"line_number":78,"context_line":"------------"},{"line_number":79,"context_line":""},{"line_number":80,"context_line":"Since we need access rule protections between users of the same project, we"},{"line_number":81,"context_line":"don\u0027t have many approaches but to imprint the user\u0027s identity into the"},{"line_number":82,"context_line":"access rule. This feature can be limited to \"admin\" and \"service\" users only."},{"line_number":83,"context_line":"It\u0027d be easier to implement the visibility and manipulation restrictions"}],"source_content_type":"text/x-rst","patch_set":1,"id":"4cbe765e_30c1ccde","line":80,"in_reply_to":"f413dc5a_93d7c69b","updated":"2023-05-18 17:03:15.000000000","message":"i see this as being very similar to the volume attachments interface as far as policy goes... from what i understand:\n\n1) User asks Nova to attach a volume to their VM \n2) Nova uses the user\u0027s context to create the cinder volume attachment\n3) User can see that the attachment object exists, but\n4) User cannot delete/modify the volume attachment, only Nova can\n\nSo transfer that to VirtIOFS:\n\n1) User asks Nova to attach a share to their VM\n2) Nova uses the user\u0027s context to create a restricted access rule\n3) User can \"see\" that a the rule exists, but,\n4) User cannot see the \"access_to\", \"access_key\" in the rule, nor delete the rule or modify the restrictions, only Nova can","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":30407,"name":"haixin","email":"haixin_haixin@qq.com","username":"haixin"},"change_message_id":"9c706dbb35091aeb28ef77e19542bae9f75e9e41","unresolved":true,"context_lines":[{"line_number":109,"context_line":"    | access_key   | varchar(255) | YES  |     | NULL    |       |"},{"line_number":110,"context_line":"    +--------------+--------------+------+-----+---------+-------+"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"The ``user_id`` field is nullable. No data is copied over during a migration"},{"line_number":113,"context_line":"because we cannot reliably ascertain which user created an access rule. This"},{"line_number":114,"context_line":"also would mean that access rule restrictions cannot apply to existing"},{"line_number":115,"context_line":"access rules. Users would have to re-create the access rule in order to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f0773a6d_e9f64079","line":112,"range":{"start_line":112,"start_character":58,"end_line":112,"end_character":76},"updated":"2023-05-04 03:09:25.000000000","message":"and also share transfer accept can not copy this \u0027user_id\u0027 filed.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"2dbf55b6ddaaf51943f09d8ebd3dda075f012473","unresolved":false,"context_lines":[{"line_number":109,"context_line":"    | access_key   | varchar(255) | YES  |     | NULL    |       |"},{"line_number":110,"context_line":"    +--------------+--------------+------+-----+---------+-------+"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"The ``user_id`` field is nullable. No data is copied over during a migration"},{"line_number":113,"context_line":"because we cannot reliably ascertain which user created an access rule. This"},{"line_number":114,"context_line":"also would mean that access rule restrictions cannot apply to existing"},{"line_number":115,"context_line":"access rules. Users would have to re-create the access rule in order to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"4e62d7e9_5b7eedfc","line":112,"range":{"start_line":112,"start_character":58,"end_line":112,"end_character":76},"in_reply_to":"79e94361_248fcab6","updated":"2023-07-06 17:25:37.000000000","message":"Done","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":30407,"name":"haixin","email":"haixin_haixin@qq.com","username":"haixin"},"change_message_id":"28c9fefcd4f1403c79b0fa15070d9f60fb76ba78","unresolved":true,"context_lines":[{"line_number":109,"context_line":"    | access_key   | varchar(255) | YES  |     | NULL    |       |"},{"line_number":110,"context_line":"    +--------------+--------------+------+-----+---------+-------+"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"The ``user_id`` field is nullable. No data is copied over during a migration"},{"line_number":113,"context_line":"because we cannot reliably ascertain which user created an access rule. This"},{"line_number":114,"context_line":"also would mean that access rule restrictions cannot apply to existing"},{"line_number":115,"context_line":"access rules. Users would have to re-create the access rule in order to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"eb1ab77c_a47c0795","line":112,"range":{"start_line":112,"start_character":58,"end_line":112,"end_character":76},"in_reply_to":"9d65ccad_86fd8325","updated":"2023-05-05 02:01:52.000000000","message":"i think here already have clear_rules parameter in share transfer.\nif a share has restricted access rules.\nwhen a user to accept a share transfer.\n1: if clear_rules is True. we can also ignore restricted access rules.\n2: if clear_rules if False, we should check whether if context.user_id \u003d\u003d access_rule.user_id.\n   if not equal, should raise to prevent share accept.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"adff7d83e3a1c7cdca8f7d71809679fe7e481a4b","unresolved":true,"context_lines":[{"line_number":109,"context_line":"    | access_key   | varchar(255) | YES  |     | NULL    |       |"},{"line_number":110,"context_line":"    +--------------+--------------+------+-----+---------+-------+"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"The ``user_id`` field is nullable. No data is copied over during a migration"},{"line_number":113,"context_line":"because we cannot reliably ascertain which user created an access rule. This"},{"line_number":114,"context_line":"also would mean that access rule restrictions cannot apply to existing"},{"line_number":115,"context_line":"access rules. Users would have to re-create the access rule in order to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"79e94361_248fcab6","line":112,"range":{"start_line":112,"start_character":58,"end_line":112,"end_character":76},"in_reply_to":"bdf2df16_2ea0797e","updated":"2023-06-14 05:44:58.000000000","message":"clarified below.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"876f1ec74c0d5e1418a3fea4810caef8f21b843d","unresolved":true,"context_lines":[{"line_number":109,"context_line":"    | access_key   | varchar(255) | YES  |     | NULL    |       |"},{"line_number":110,"context_line":"    +--------------+--------------+------+-----+---------+-------+"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"The ``user_id`` field is nullable. No data is copied over during a migration"},{"line_number":113,"context_line":"because we cannot reliably ascertain which user created an access rule. This"},{"line_number":114,"context_line":"also would mean that access rule restrictions cannot apply to existing"},{"line_number":115,"context_line":"access rules. Users would have to re-create the access rule in order to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bdf2df16_2ea0797e","line":112,"range":{"start_line":112,"start_character":58,"end_line":112,"end_character":76},"in_reply_to":"eb1ab77c_a47c0795","updated":"2023-05-18 17:03:15.000000000","message":"True; but there could be several restricted rules belonging to different users;","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"466905e9c10138b5a829887f93005a55d42f69c9","unresolved":true,"context_lines":[{"line_number":109,"context_line":"    | access_key   | varchar(255) | YES  |     | NULL    |       |"},{"line_number":110,"context_line":"    +--------------+--------------+------+-----+---------+-------+"},{"line_number":111,"context_line":""},{"line_number":112,"context_line":"The ``user_id`` field is nullable. No data is copied over during a migration"},{"line_number":113,"context_line":"because we cannot reliably ascertain which user created an access rule. This"},{"line_number":114,"context_line":"also would mean that access rule restrictions cannot apply to existing"},{"line_number":115,"context_line":"access rules. Users would have to re-create the access rule in order to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"9d65ccad_86fd8325","line":112,"range":{"start_line":112,"start_character":58,"end_line":112,"end_character":76},"in_reply_to":"f0773a6d_e9f64079","updated":"2023-05-04 17:47:12.000000000","message":"I should clarify this is a database migration... but i get your point about share transfers. Restricted access rules may not make sense when shares are transferred across projects. In the limited scenario where a user is part of two projects, these restrictions could be preserved... So, i\u0027m thinking we should add some logic to the transfer_start API to check for restricted rules, and if there are any, warn about this and fail the transfer... we can add an API parameter to perform the transfer acknowledging that there are restricted rules.. \n\nwdyt?","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":30407,"name":"haixin","email":"haixin_haixin@qq.com","username":"haixin"},"change_message_id":"9c706dbb35091aeb28ef77e19542bae9f75e9e41","unresolved":true,"context_lines":[{"line_number":140,"context_line":"        \"allow_access\": {"},{"line_number":141,"context_line":"            \"access_type\": \"ip\","},{"line_number":142,"context_line":"            \"access_to\": \"203.0.113.10\","},{"line_number":143,"context_line":"            \"metadata\":{"},{"line_number":144,"context_line":"                \"restrict_visibility\": \"True\","},{"line_number":145,"context_line":"                \"restrict_deletion\": \"True\","},{"line_number":146,"context_line":"            }"}],"source_content_type":"text/x-rst","patch_set":1,"id":"db65acc4_794b08b9","line":143,"range":{"start_line":143,"start_character":13,"end_line":143,"end_character":21},"updated":"2023-05-04 03:09:25.000000000","message":"what is the default value? if we not provide metadata?\nrestrict_visibility and restrict_deletion default is False?\nand user_id share_access_map is null?","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":30407,"name":"haixin","email":"haixin_haixin@qq.com","username":"haixin"},"change_message_id":"28c9fefcd4f1403c79b0fa15070d9f60fb76ba78","unresolved":false,"context_lines":[{"line_number":140,"context_line":"        \"allow_access\": {"},{"line_number":141,"context_line":"            \"access_type\": \"ip\","},{"line_number":142,"context_line":"            \"access_to\": \"203.0.113.10\","},{"line_number":143,"context_line":"            \"metadata\":{"},{"line_number":144,"context_line":"                \"restrict_visibility\": \"True\","},{"line_number":145,"context_line":"                \"restrict_deletion\": \"True\","},{"line_number":146,"context_line":"            }"}],"source_content_type":"text/x-rst","patch_set":1,"id":"8bb751f3_225088e1","line":143,"range":{"start_line":143,"start_character":13,"end_line":143,"end_character":21},"in_reply_to":"16d36c2e_b470a6c6","updated":"2023-05-05 02:01:52.000000000","message":"that means if there is no those options in metadata is equal to set False in metadata. this is ok for me.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"466905e9c10138b5a829887f93005a55d42f69c9","unresolved":true,"context_lines":[{"line_number":140,"context_line":"        \"allow_access\": {"},{"line_number":141,"context_line":"            \"access_type\": \"ip\","},{"line_number":142,"context_line":"            \"access_to\": \"203.0.113.10\","},{"line_number":143,"context_line":"            \"metadata\":{"},{"line_number":144,"context_line":"                \"restrict_visibility\": \"True\","},{"line_number":145,"context_line":"                \"restrict_deletion\": \"True\","},{"line_number":146,"context_line":"            }"}],"source_content_type":"text/x-rst","patch_set":1,"id":"16d36c2e_b470a6c6","line":143,"range":{"start_line":143,"start_character":13,"end_line":143,"end_character":21},"in_reply_to":"db65acc4_794b08b9","updated":"2023-05-04 17:47:12.000000000","message":"user_id is always populated on newly created rules.. if the \"user_id\" field is none, a rule cannot be restricted.. \n\nThe default behavior is that rules aren\u0027t restricted.. I didn\u0027t think we need those options set in the metadata if they\u0027re false. but I guess it doesn\u0027t hurt.. \n\nDo you think it\u0027s useful to expose them as \"False\"?","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"a530151bf2a576817246a4eab8c4a64f767a8f86","unresolved":true,"context_lines":[{"line_number":162,"context_line":"            \"id\": \"a25b2df3-90bd-4add-afa6-5f0dbbd50452\","},{"line_number":163,"context_line":"            \"user_id\": \"237dfe73c4b14064a67e195ce246f1a2\","},{"line_number":164,"context_line":"            \"metadata\":{"},{"line_number":165,"context_line":"                \"restrict_visibility\": \"True\","},{"line_number":166,"context_line":"                \"restrict_deletion\": \"True\","},{"line_number":167,"context_line":"            }"},{"line_number":168,"context_line":"        }"}],"source_content_type":"text/x-rst","patch_set":1,"id":"90747316_f051068a","line":165,"range":{"start_line":165,"start_character":16,"end_line":165,"end_character":45},"updated":"2023-05-05 15:48:09.000000000","message":"I believe that the restrict_visibility mechanism should be expanded to cover shares, in order to mask the export location. This would provide greater control over the visibility of sensitive information such as Ceph internal IP addresses. I think this would be a valuable feature for customers who have concerns about exposing this type of information.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"876f1ec74c0d5e1418a3fea4810caef8f21b843d","unresolved":true,"context_lines":[{"line_number":162,"context_line":"            \"id\": \"a25b2df3-90bd-4add-afa6-5f0dbbd50452\","},{"line_number":163,"context_line":"            \"user_id\": \"237dfe73c4b14064a67e195ce246f1a2\","},{"line_number":164,"context_line":"            \"metadata\":{"},{"line_number":165,"context_line":"                \"restrict_visibility\": \"True\","},{"line_number":166,"context_line":"                \"restrict_deletion\": \"True\","},{"line_number":167,"context_line":"            }"},{"line_number":168,"context_line":"        }"}],"source_content_type":"text/x-rst","patch_set":1,"id":"f8a8225a_254e9dd0","line":165,"range":{"start_line":165,"start_character":16,"end_line":165,"end_character":45},"in_reply_to":"90747316_f051068a","updated":"2023-05-18 17:03:15.000000000","message":"ack, but i haven\u0027t heard this being a concern so far... if the IPs are sensitive, we\u0027ve known administrators to use hostnames resolvable by DNS. In case of Ceph, typically, the ceph public network needs to be accessible to user workloads - a very permissive trust model since that\u0027s the network that several ceph daemons operate on. So gatewaying Ceph via NFS seems more popular in multitenant clouds - where again, exposing the IP/hostname of the server in the export location seems less risky.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"adff7d83e3a1c7cdca8f7d71809679fe7e481a4b","unresolved":false,"context_lines":[{"line_number":162,"context_line":"            \"id\": \"a25b2df3-90bd-4add-afa6-5f0dbbd50452\","},{"line_number":163,"context_line":"            \"user_id\": \"237dfe73c4b14064a67e195ce246f1a2\","},{"line_number":164,"context_line":"            \"metadata\":{"},{"line_number":165,"context_line":"                \"restrict_visibility\": \"True\","},{"line_number":166,"context_line":"                \"restrict_deletion\": \"True\","},{"line_number":167,"context_line":"            }"},{"line_number":168,"context_line":"        }"}],"source_content_type":"text/x-rst","patch_set":1,"id":"73c1bce8_81bed5fc","line":165,"range":{"start_line":165,"start_character":16,"end_line":165,"end_character":45},"in_reply_to":"f8a8225a_254e9dd0","updated":"2023-06-14 05:44:58.000000000","message":"Done","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"change_message_id":"fbf6b1f8b0644afd16298f42ffcc0cfe8e45faf9","unresolved":true,"context_lines":[{"line_number":169,"context_line":"    }"},{"line_number":170,"context_line":""},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"**Update restrictions on an access rule**::"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"  PUT /share-access-rules/{id}/metadata"},{"line_number":175,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"df951a37_030d51fa","line":172,"updated":"2023-05-16 21:52:13.000000000","message":"unless we restirct this and the creation of restirted_deleteion accesse rules to the service role i dont think this is a good api.\n\nand im not conviced that is the right approch for standaone mainlly \n\nbecause if we accept that we might want to have user scoped \"private\" accell rules to restict who can acces the cephx key for example then that woudl be usefual in a standalone context too so we dont really want to force the service role there.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"adff7d83e3a1c7cdca8f7d71809679fe7e481a4b","unresolved":false,"context_lines":[{"line_number":169,"context_line":"    }"},{"line_number":170,"context_line":""},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"**Update restrictions on an access rule**::"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"  PUT /share-access-rules/{id}/metadata"},{"line_number":175,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"22bc8d27_daa00e3d","line":172,"in_reply_to":"09545240_e0e46c7f","updated":"2023-06-14 05:44:58.000000000","message":"for the use case you mentioned at the end of your comment :)","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"876f1ec74c0d5e1418a3fea4810caef8f21b843d","unresolved":true,"context_lines":[{"line_number":169,"context_line":"    }"},{"line_number":170,"context_line":""},{"line_number":171,"context_line":""},{"line_number":172,"context_line":"**Update restrictions on an access rule**::"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"  PUT /share-access-rules/{id}/metadata"},{"line_number":175,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"09545240_e0e46c7f","line":172,"in_reply_to":"df951a37_030d51fa","updated":"2023-05-18 17:03:15.000000000","message":"yes, i agree on not limiting this only to \"service\" users..","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":30407,"name":"haixin","email":"haixin_haixin@qq.com","username":"haixin"},"change_message_id":"9c706dbb35091aeb28ef77e19542bae9f75e9e41","unresolved":true,"context_lines":[{"line_number":171,"context_line":""},{"line_number":172,"context_line":"**Update restrictions on an access rule**::"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"  PUT /share-access-rules/{id}/metadata"},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"Normal http response code(s):"},{"line_number":177,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"3107984e_e166ecbd","line":174,"range":{"start_line":174,"start_character":2,"end_line":174,"end_character":39},"updated":"2023-05-04 03:09:25.000000000","message":"user A create an access rule for shareA(now user A has know the id of this rule), but without set visibility metadata.\nthen user B see this rule, then call this PUT rest to set visibility metadata for user B.\nthen user A can not see this rule, Can user A call this PUT rest to reset visibility metadata? \nif user A can do this, User B must have felt very strange.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"466905e9c10138b5a829887f93005a55d42f69c9","unresolved":true,"context_lines":[{"line_number":171,"context_line":""},{"line_number":172,"context_line":"**Update restrictions on an access rule**::"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"  PUT /share-access-rules/{id}/metadata"},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"Normal http response code(s):"},{"line_number":177,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"c4c4ef4a_64615411","line":174,"range":{"start_line":174,"start_character":2,"end_line":174,"end_character":39},"in_reply_to":"3107984e_e166ecbd","updated":"2023-05-04 17:47:12.000000000","message":"This won\u0027t be possible. Only the user that created the rule can set visibility and deletion restrictions. If user B performs this request, they\u0027ll get a 403..I can clarify this after line 184","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":30407,"name":"haixin","email":"haixin_haixin@qq.com","username":"haixin"},"change_message_id":"28c9fefcd4f1403c79b0fa15070d9f60fb76ba78","unresolved":false,"context_lines":[{"line_number":171,"context_line":""},{"line_number":172,"context_line":"**Update restrictions on an access rule**::"},{"line_number":173,"context_line":""},{"line_number":174,"context_line":"  PUT /share-access-rules/{id}/metadata"},{"line_number":175,"context_line":""},{"line_number":176,"context_line":"Normal http response code(s):"},{"line_number":177,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"fcfdb2fd_20254746","line":174,"range":{"start_line":174,"start_character":2,"end_line":174,"end_character":39},"in_reply_to":"c4c4ef4a_64615411","updated":"2023-05-05 02:01:52.000000000","message":"i got it.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"466905e9c10138b5a829887f93005a55d42f69c9","unresolved":true,"context_lines":[{"line_number":236,"context_line":"- 406 - API version not supported"},{"line_number":237,"context_line":""},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"When an access rule has visibility restrictions applied a different user"},{"line_number":240,"context_line":"without the \"admin\" role will see the ``access_to`` and ``access_secret``"},{"line_number":241,"context_line":"fields set to ``null``."},{"line_number":242,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"c6bfdb1f_5944e736","line":239,"range":{"start_line":239,"start_character":55,"end_line":239,"end_character":56},"updated":"2023-05-04 17:47:12.000000000","message":"nit: missing a comma","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"adff7d83e3a1c7cdca8f7d71809679fe7e481a4b","unresolved":false,"context_lines":[{"line_number":236,"context_line":"- 406 - API version not supported"},{"line_number":237,"context_line":""},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"When an access rule has visibility restrictions applied a different user"},{"line_number":240,"context_line":"without the \"admin\" role will see the ``access_to`` and ``access_secret``"},{"line_number":241,"context_line":"fields set to ``null``."},{"line_number":242,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"ce5db2c5_091204eb","line":239,"range":{"start_line":239,"start_character":55,"end_line":239,"end_character":56},"in_reply_to":"c6bfdb1f_5944e736","updated":"2023-06-14 05:44:58.000000000","message":"Done","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16207,"name":"ribaudr","display_name":"uggla","email":"rene.ribaud@gmail.com","username":"uggla","status":"Red Hat"},"change_message_id":"a530151bf2a576817246a4eab8c4a64f767a8f86","unresolved":true,"context_lines":[{"line_number":238,"context_line":""},{"line_number":239,"context_line":"When an access rule has visibility restrictions applied a different user"},{"line_number":240,"context_line":"without the \"admin\" role will see the ``access_to`` and ``access_secret``"},{"line_number":241,"context_line":"fields set to ``null``."},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"When an access rule has a deletion restriction, a different user without the"},{"line_number":244,"context_line":"\"admin\" role will receive a HTTP 403 Forbidden error when they attempt to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"7a65960f_74d1d603","line":241,"range":{"start_line":241,"start_character":16,"end_line":241,"end_character":20},"updated":"2023-05-05 15:48:09.000000000","message":"Rather than using null, we could consider using ``******`` to more clearly indicate that the information is available but masked due to insufficient privileges.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":30407,"name":"haixin","email":"haixin_haixin@qq.com","username":"haixin"},"change_message_id":"9c706dbb35091aeb28ef77e19542bae9f75e9e41","unresolved":true,"context_lines":[{"line_number":237,"context_line":""},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"When an access rule has visibility restrictions applied a different user"},{"line_number":240,"context_line":"without the \"admin\" role will see the ``access_to`` and ``access_secret``"},{"line_number":241,"context_line":"fields set to ``null``."},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"When an access rule has a deletion restriction, a different user without the"},{"line_number":244,"context_line":"\"admin\" role will receive a HTTP 403 Forbidden error when they attempt to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"8b1303eb_929540dd","line":241,"range":{"start_line":240,"start_character":30,"end_line":241,"end_character":23},"updated":"2023-05-04 03:09:25.000000000","message":"different user can still see this rule, although ``access_to`` and ``access_secret`` is null.  how about not let different user see this rule?","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"adff7d83e3a1c7cdca8f7d71809679fe7e481a4b","unresolved":false,"context_lines":[{"line_number":238,"context_line":""},{"line_number":239,"context_line":"When an access rule has visibility restrictions applied a different user"},{"line_number":240,"context_line":"without the \"admin\" role will see the ``access_to`` and ``access_secret``"},{"line_number":241,"context_line":"fields set to ``null``."},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"When an access rule has a deletion restriction, a different user without the"},{"line_number":244,"context_line":"\"admin\" role will receive a HTTP 403 Forbidden error when they attempt to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"8b6b8a87_3609967b","line":241,"range":{"start_line":241,"start_character":16,"end_line":241,"end_character":20},"in_reply_to":"37b30931_229c0cab","updated":"2023-06-14 05:44:58.000000000","message":"Done","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"876f1ec74c0d5e1418a3fea4810caef8f21b843d","unresolved":true,"context_lines":[{"line_number":238,"context_line":""},{"line_number":239,"context_line":"When an access rule has visibility restrictions applied a different user"},{"line_number":240,"context_line":"without the \"admin\" role will see the ``access_to`` and ``access_secret``"},{"line_number":241,"context_line":"fields set to ``null``."},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"When an access rule has a deletion restriction, a different user without the"},{"line_number":244,"context_line":"\"admin\" role will receive a HTTP 403 Forbidden error when they attempt to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"37b30931_229c0cab","line":241,"range":{"start_line":241,"start_character":16,"end_line":241,"end_character":20},"in_reply_to":"7a65960f_74d1d603","updated":"2023-05-18 17:03:15.000000000","message":"I see; ack.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"466905e9c10138b5a829887f93005a55d42f69c9","unresolved":true,"context_lines":[{"line_number":237,"context_line":""},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"When an access rule has visibility restrictions applied a different user"},{"line_number":240,"context_line":"without the \"admin\" role will see the ``access_to`` and ``access_secret``"},{"line_number":241,"context_line":"fields set to ``null``."},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"When an access rule has a deletion restriction, a different user without the"},{"line_number":244,"context_line":"\"admin\" role will receive a HTTP 403 Forbidden error when they attempt to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"cd008a8a_00861d48","line":241,"range":{"start_line":240,"start_character":30,"end_line":241,"end_character":23},"in_reply_to":"8b1303eb_929540dd","updated":"2023-05-04 17:47:12.000000000","message":"I thought about this; hiding the rule\u0027s existence from other project users didn\u0027t seem like a useful thing.. the reason is that I have joint ownership for a share in my project, and i would like to know if someone is using the share --- not necessarily where (``access_to``) and what their access secret is. This would help me determine the impact of making changes to the share that may adversely affect the usage.. an adverse action could be: shrinking the share, reverting to a snapshot, promoting a replica, deleting the share, etc.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":30407,"name":"haixin","email":"haixin_haixin@qq.com","username":"haixin"},"change_message_id":"28c9fefcd4f1403c79b0fa15070d9f60fb76ba78","unresolved":false,"context_lines":[{"line_number":237,"context_line":""},{"line_number":238,"context_line":""},{"line_number":239,"context_line":"When an access rule has visibility restrictions applied a different user"},{"line_number":240,"context_line":"without the \"admin\" role will see the ``access_to`` and ``access_secret``"},{"line_number":241,"context_line":"fields set to ``null``."},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"When an access rule has a deletion restriction, a different user without the"},{"line_number":244,"context_line":"\"admin\" role will receive a HTTP 403 Forbidden error when they attempt to"}],"source_content_type":"text/x-rst","patch_set":1,"id":"d888f5d2_087e91f9","line":241,"range":{"start_line":240,"start_character":30,"end_line":241,"end_character":23},"in_reply_to":"cd008a8a_00861d48","updated":"2023-05-05 02:01:52.000000000","message":"ok, whether a share has access rule is an important information for user. i got this. thanks.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":30407,"name":"haixin","email":"haixin_haixin@qq.com","username":"haixin"},"change_message_id":"9c706dbb35091aeb28ef77e19542bae9f75e9e41","unresolved":true,"context_lines":[{"line_number":241,"context_line":"fields set to ``null``."},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"When an access rule has a deletion restriction, a different user without the"},{"line_number":244,"context_line":"\"admin\" role will receive a HTTP 403 Forbidden error when they attempt to"},{"line_number":245,"context_line":"delete the rule."},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"The REST API micro version will be increased indicating these new features."}],"source_content_type":"text/x-rst","patch_set":1,"id":"4396981f_473e671a","line":244,"range":{"start_line":244,"start_character":18,"end_line":244,"end_character":46},"updated":"2023-05-04 03:09:25.000000000","message":"if different user without \u0027admin\u0027 role can not see this rule, These users would not be able to delete the rule， since they don\u0027t know the id of access rule.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":30407,"name":"haixin","email":"haixin_haixin@qq.com","username":"haixin"},"change_message_id":"28c9fefcd4f1403c79b0fa15070d9f60fb76ba78","unresolved":false,"context_lines":[{"line_number":241,"context_line":"fields set to ``null``."},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"When an access rule has a deletion restriction, a different user without the"},{"line_number":244,"context_line":"\"admin\" role will receive a HTTP 403 Forbidden error when they attempt to"},{"line_number":245,"context_line":"delete the rule."},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"The REST API micro version will be increased indicating these new features."}],"source_content_type":"text/x-rst","patch_set":1,"id":"7eb5d8f5_d8df5f5c","line":244,"range":{"start_line":244,"start_character":18,"end_line":244,"end_character":46},"in_reply_to":"18625a7c_37c28fee","updated":"2023-05-05 02:01:52.000000000","message":"ack.","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"466905e9c10138b5a829887f93005a55d42f69c9","unresolved":true,"context_lines":[{"line_number":241,"context_line":"fields set to ``null``."},{"line_number":242,"context_line":""},{"line_number":243,"context_line":"When an access rule has a deletion restriction, a different user without the"},{"line_number":244,"context_line":"\"admin\" role will receive a HTTP 403 Forbidden error when they attempt to"},{"line_number":245,"context_line":"delete the rule."},{"line_number":246,"context_line":""},{"line_number":247,"context_line":"The REST API micro version will be increased indicating these new features."}],"source_content_type":"text/x-rst","patch_set":1,"id":"18625a7c_37c28fee","line":244,"range":{"start_line":244,"start_character":18,"end_line":244,"end_character":46},"in_reply_to":"4396981f_473e671a","updated":"2023-05-04 17:47:12.000000000","message":"true, but answered above about why we could let them still see these rules..","commit_id":"68bdcb2e0c52b4ab057aab04448fcf1e4a9179a8"}]}