Optionally allow following symlinks #26
Comments
This commit fixes some issues with `write_uid_gid_maps()` which in turn allows us to finally assign a proper user ID and group ID to our sandboxed process, so now the `Sandbox::uid()` and `Sandbox::gid()` builder methods actually do something. If the user doesn't specify them, the sandbox defaults to inheriting the same user and group as the parent process. There were a handful of issues with coaxing the `openat` library to do the right thing, first of which was described in tailhook/openat#26. Another unsolved issue is that `writeln!()` and `write!()` sometimes strangely fails when writing to files opened with `openat::Dir::write_file()`, namely it throws an `std::io::ErrorKind::InvalidInput` with the message "Invalid argument". The panic itself appears to be coming from `std::io::Write::write_fmt()` specfically when invoked on `/proc/self/{uid_map,gid_map}`. Thankfully, when I use `<File as Write>::write_all()`, it works just fine, and I can verify from within the sandboxed process that the UIDs and GIDs are indeed set up correctly from the write. Strange, but at least this works. :shrug:
This commit fixes some issues with `write_uid_gid_maps()` which in turn allows us to finally assign a proper user ID and group ID to our sandboxed process, so now the `Sandbox::uid()` and `Sandbox::gid()` builder methods actually do something. If the user doesn't specify them, the sandbox defaults to inheriting the same user and group as the parent process. There were a handful of issues with coaxing the `openat` library to do the right thing, first of which was described in tailhook/openat#26. Another unsolved issue is that `writeln!()` and `write!()` sometimes strangely fails when writing to files opened with `openat::Dir::write_file()`, namely it throws an `std::io::ErrorKind::InvalidInput` with the message "Invalid argument". The panic itself appears to be coming from `std::io::Write::write_fmt()` specifically when invoked on `/proc/self/{uid_map,gid_map}`. Thankfully, when I use `<File as Write>::write_all()`, it works just fine, and I can verify from within the sandboxed process that the UIDs and GIDs are indeed set up correctly from the write. Strange, but at least this works. :shrug:
|
I'm happy to accept PR for a documentation update. For the flag: I think we should do that at some point. But we must do it considering #18 and #25 too. (i.e. some "open with options" method). So I'm not sure I can allocate time for it soon. Just to know the context: any specific reason you're using |
|
Sounds good! I'd be happy to open a PR with just the documentation update for now and close this issue in favor of #18, since I believe its scope encompasses this one. In the sandboxing library I'm developing, I open the Because of this, I chose to keep a lone file descriptor for With that said, I'm still polishing and simplifying this architecture, so it isn't final. |
It appears that
Dir::sub_dir()always forces theO_NOFOLLOWflag when accessing files or subdirectories, which isn't always ideal. In my case, I was struggling to open the/proc/selfsubdirectory, until I eventually realized that I needed to perform the following dance to make it work:This was surprising, as this was inconsistent with the default behavior of
openat()and the IO error it produces was initially mystifying (it simply stated "Not a directory").It would be nice if users could specify with a boolean flag on
sub_dir()whether they would like to follow symlinks or not. At the very least, I think the documentation forsub_dir()should mention that symlinked subdirectories require the use ofread_link()to resolve the real path before attempting to access it.The text was updated successfully, but these errors were encountered: