-
Notifications
You must be signed in to change notification settings - Fork 356
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Init a selinux project #2800
Init a selinux project #2800
Conversation
I'm not familiar with this area. So, It would be nice if you could make the PR small enough so that one function could run on e2e. |
Sure, thanks! |
Signed-off-by: Hiroyuki Moriya <[email protected]>
This PR is the perfect size for me to review! Thanks. But sorry, I'll revisit it next weekend 🙏 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, some comments, some nitpicks, overall the implementation seems to be going in the right direction 👍
Can we add doc comments for all the pub
functions (which are implemented here), so it will be easier to review what the function is supposed to do + documentation
minor nitpicks :
- instead of
panic!(...)
I feelunimplemented!()
would be a better fit. Even though both behave the same, I feel unimplemented is semantically better. I am not asking to change the current use, but maybe for future PRs. - Can you check if clippy is run here and does not give any errors? I have had issues in past when running clippy in CI with projects excluded via cargo.toml.
experiment/selinux/src/selinux.rs
Outdated
ATTR_PATH_INIT.call_once(|| { | ||
let path = PathBuf::from(THREAD_SELF_PREFIX); | ||
unsafe { | ||
HAVE_THREAD_SELF = path.is_dir(); | ||
} | ||
}); | ||
|
||
unsafe { | ||
if HAVE_THREAD_SELF { | ||
return format!("{}/{}", THREAD_SELF_PREFIX, attr); | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain the use of this function? I am not able to understand it correctly 😅
- What is the reason for using Once and call_once here? Assuming youki as the primary use-case, is there still a chance of having a multi-thread race? If so can be use AtomicBool instead and remove dependency of Once? (Suggesting as underlying data is simple bool type). We might be able to do an compare-and-exchange operation instead of the call_once here.
- Do we need the
unsafe
block if we are only reading theHAVE_THREAD_SELF
value? I thought unsafe was needed only if we were writing to the variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I've updated the code using atomicBool instead.
I implemented using Once because go-selinux implemented like that.
I guess that this is to avoid conflicts between multi-thread like goroutine.
I thought it is possible that similar issue happens on Youki as well.
https://github.com/opencontainers/selinux/blob/9dee859cbffb974e779f65efaef9f5ef6e1d260b/go-selinux/selinux_linux.go#L451-L467
I am not familiar with selinux nor youki, so please let me know if I misunderstood.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey, thanks. I am also not that familiar with selinux-go, so will take a look and confirm once.
Signed-off-by: Hiroyuki Moriya <[email protected]>
a9f7e00
to
15c71b1
Compare
Signed-off-by: Hiroyuki Moriya <[email protected]>
Signed-off-by: Hiroyuki Moriya <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @Gekko0114! This is a good first step for us. I left some comments.
experiment/selinux/src/selinux.rs
Outdated
// function compatible with lSetFileLabel in go-selinux repo. | ||
// lset_file_label sets the SELinux label for this path, not following symlinks, | ||
// or returns an error. | ||
pub fn lset_file_label(fpath: &str, label: &str) -> Result<(), std::io::Error> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should introduce the thiserror
crate instead of std::io::Error
at some point in the future or in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I introduced thiserror
. Please let me know if I don't use thiserror
correctly.
experiment/selinux/src/selinux.rs
Outdated
static HAVE_THREAD_SELF: AtomicBool = AtomicBool::new(false); | ||
static INIT_DONE: AtomicBool = AtomicBool::new(false); | ||
|
||
// function compatible with setDisabled in go-selinux repo. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we have to keep it compatible with the go-selinux
repo. Is there any specific reason to keep it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my view, prioritizing Rust-friendliness over maintaining compatibility with go-selinux
is more important.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my view, prioritizing Rust-friendliness over maintaining compatibility with go-selinux is more important.
Yeah, agree. I couldn't write Rust-friendliness well because I am not so familiar with Rust yet.
Please let me know if you feel weird in terms of Rust. Thank you so much!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please let me know if you feel weird in terms of Rust. Thank you so much!
Sure. First of all, we can take using struct
instead of global variables into consideration. WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, as you commented in another thread, I will use struct.
I will fix it after reading experiment/seccomp and other codes.
If we use struct
here and call this struct
more than once, I thought maybe the selinux struct is initialized more than once. But the performance caused by this is tiny, so I will use struct here.
Signed-off-by: Hiroyuki Moriya <[email protected]>
Signed-off-by: Hiroyuki Moriya <[email protected]>
Signed-off-by: Hiroyuki Moriya <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks good to me as a first PR for a Selinxu project. In the next PR, it'd be great if there was an excellent example to run with the selinux
crate.
@utam0k |
Thanks, @Gekko0114 ! Great work! |
This is an experimental crate. I'll implement a selinux crate step-by-step.
When it is mature, I'll move it under the 'crate/' and use it.
ref: #2718