fix: access to files needed for user management #220
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
st3v3nmw
force-pushed
the
mount-etc
branch
2 times, most recently
from
f8d0cc0
to
e81d645
Compare
|
Looks like it's impossible to get around that seccomp violation. Way out is to use D-Bus & the Closed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TL;DR
This change grants write permissions to files, folders, and interfaces required for user management to work on the snap when it's running on Ubuntu classic.
DETAILS
After #218, I realized I was testing in
devmodewhere permissions are lax. After switching todangerouswhich is strict, I realized that nothing works 😞. This PR should get landscape-client snap's user management working on Ubuntu classic.Here's a laundry list of the issues I played whack-a-mole with along the way (it should also justify choices made with the fixes):
1.
adduseroverwriting$PATHTrying to run
adduserinside the snap's shell (essentially whatlandscape.client.user.management.UserManagementdoes) led to the following error:The issue here is we're trying to use
/sbin/groupaddwhich we don't have access to:Though we already have groupadd inside the snap (from the staged
passwdpackage):Digging deeper, we find that the adduser package modifies
$PATHhere:Then it runs
whichwith the modified$PATHhere:The fix here is to delete the offending line while building the snap:
2. Access to the kernel's audit interface
Next, we find that
groupaddcan't open the kernel's audit interface:Fixed by adding the netlink-audit interface.
3. Read & write access to
/etcNext, we find that
groupaddcan't create the/etc/group.locklock file to prevent simultaneous updates to/etc/group.Tried fixing this by plugging the system-files interface with read & write access to the following files:
And it still doesn't work since
groupaddkeeps creating files with random suffixes/etc/group.N:We also can't use patterns like
/etc/group*withsystems-filesas they're not supported:So the fix here is to give read & write access to the entire
/etcfolder. But it still doesn't work because the folder structure is all messed up inside the snap since we're mounting/etcwithsystem-filesand also creating a virtual file system/etcwithlayout:Which means that changes made to files like
/etc/groupdo not appear on the host's file system. Getting rid of the/etc/landscape-client.conflayout fixes this.4. Permission issues writing to
/etc/shadow&/etc/gshadowAt this point we can write to
/etc/groupbut can't write to/etc/gshadowwhich means that adding users isn't yet working. If we check thejournalctllogs, we see:In the
SECCOMPlog, we find that we're attempting to do syscall 93 which is fchown which is being blocked by seccomp/AppArmor. We can confirm this by checking landscape client's AppArmor profile and see that thechowncapability is not enabled/set:Luckily, the account control interface grants us this capability:
from snapd/interfaces/builtin/account_control.go#L99
Which also updates our seccomp profile (
cat /var/lib/snapd/seccomp/bpf/snap.landscape-client.landscape-client.src):5. Can't create home directories for new users
Next, we realize that we can't create home directories for new users:
Adding the
homeinterface still leads to the same error. It seems like we don't have write access even though the folder is loaded asread-write?If we add
/hometosystem-filesit still fails due tochownbut we're able to create the user's home directory: