Skip to content
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

Possible issues with permissions passthrough involving executable bit along with other issues observed. #702

Open
jfmherokiller opened this issue Oct 4, 2024 · 2 comments

Comments

@jfmherokiller
Copy link

This may be an unsual method but I discovered an issue with the permissions pass through when I was trying to "install" arch to a subvolume using ubuntu 22.04 wsl as the intermedary.

I first installed a basic arch chroot inside of ubuntu using https://github.com/wick3dr0se/archstrap

then i remounted the drive letter that contains the btrfs subvolume using the command sudo mount -t drvfs j: /tmp/archrootfs/mnt/j

then from there I first tried pacstrap -K /mnt/j/@arch base linux linux-firmware

that command threw up this unrecoverable error

error: could not open file /mnt/j/@arch/var/lib/pacman/sync/download-ePxpAU/core.db.part: Permission denied
error: failed to setup a download payload for core.db
error: failed to synchronize all databases (failed to retrieve some files)

the download folder never shows up.

However you can bypass the above issue in a probably really really broken way.

First you copy the db files using cp /var/lib/pacman/sync/* /mnt/j/@arch/var/lib/pacman/sync

then you can kind of install packages via this command.

pacman -r /mnt/j/@arch -S base 

The installation will eventually "fail" with errors such as

( 1/11) Creating system user accounts...
call to execv failed (Permission denied)

This is where the main issue appears.

image

The entire Executable column is not filled in and it cant be fixed by running chmod -R +x /mnt/j/@arch/usr/bin

the correct permissions should probably be something like this

image

However you can fix it if you open each executable individually and manually apply the executable permissions bit.

But doing this for every file in /usr/bin and other directories which contain executables is ... possible todo but extremely time consuming.

Plus I dont know if the user and group values will even allow it to boot.

@maharmstone
Copy link
Owner

Yes, I noticed the same thing a few months ago, doing something similar - it's on my list of things to fix. WSL is picking up the permissions fine, but chmod etc. are silently failing.

I think quite possibly Microsoft have recently changed how WSL works.

@jfmherokiller
Copy link
Author

jfmherokiller commented Oct 5, 2024

I did also notice spots during the installation where I think the case sensitivity issues occurred. I forget which arch package it was, but I do know it involved possibly locale or keymaps.

Pretty much the package was doing this

somefolder/P/<locale or keymap thing with long name>
somefolder/p/<symlink to the larger named file>

however it seemed like the uppercase folder was failing to be made.
this allowed the package to install but probably in a broken state.

I sadly dont have the logs for that because I chose to reboot and use a livecd to install arch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants