Weedog Ubuntu Kylin: Cannot sudo

[miltonx]

I weedogged Ubuntu Kylin 20.04 pro, which boots and runs fine. But whenever I run "sudo ...", occurs this error:

Code: Select all

sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

Actually I tried two methods of making weedog ubuntu-kylin, both resulting in the above.

Method 1:
- Boot ubuntu-kylin live iso (on an easy2boot disk), then run:

Code: Select all

sudo tar -cvpzf /mnt/sda3/weedog-ubuntu-kylin/ubuntu-kylin.tar.gz --one-file-system /

- Reboot computer using fossapup (because I'm more comfortable with using puppy as root), and run:

Code: Select all

mkdir -p /mnt/sda3/weedog-ubuntu-kylin/01-ubuntu-kylin-live
tar -xvpzf /mnt/sda3/weedog-ubuntu-kylin/ubuntu-kylin.tar.gz -C /mnt/sda3/weedog-ubuntu-kylin/01-ubuntu-kylin-live/ --numeric-owner

- Copy/Modiy vmlinuz and initrd and place them in /mnt/sda3/weedog-ubuntu-kylin/, and successfully rebooted into ubuntu kylin.

Method 2:
- Use ubuntu-kylin live iso (still from that easy2boot disk) to fully install it on a usb hdd;
- Reboot computer using fossapup (again, because it's my handy daily system);
- Plug in the fully installed kylin (on sdb2), and run:

Code: Select all

cp -rp /mnt/sdb2/. /mnt/sda3/weedog-ubuntu-kylin/01-ubuntu-kylin-installed/
rm -rf /mnt/sda3/weedog-ubuntu-kylin/01-ubuntu-kylin-live

- Again successfully booted into kylin, but still not able to run "sudo".

Note: I checked the sudo file by running:

Code: Select all

ls -l /usr/bin/sudo
-rwsr-xr-x 1 root root 166056 ...

Does not seem to be a permission issue.

[rockedge]

have you attempted to reinstall the sudo package after booting? What user is the system booting and running with?

[miltonx]

have you attempted to reinstall the sudo package after booting? What user is the system booting and running with?

No, since sudo cannot be used, I cannot reinstall anything after booting.
Method 1 boots into kylin live's default user "ubuntu-kylin".
Method 2 boots into the user I set during full installation, "m".

On Kylin live and on the fully installed kylin usb drive, sudo works fine.

[miltonx]

This is the mount info. The tmpfs is mounted as nosuid.

Code: Select all

m@mcomputer:~$ mount
/dev/sda3 on /mnt/sda3 type ext4 (rw,relatime)
overlay_result on / type overlay (rw,relatime,lowerdir=01,upperdir=/mnt/layers/RAM/upper_changes,workdir=/mnt/layers/RAM/work)
rootfs on /mnt/layers type rootfs (rw,size=1549448k,nr_inodes=387362,inode64)
inram on /mnt/layers/RAM type tmpfs (rw,nosuid,nodev,relatime,size=3253416k,inode64)
/dev/sda3 on /mnt/layers/01 type ext4 (rw,relatime)
overlay_result on /mnt/layers/merged type overlay (rw,relatime,lowerdir=01,upperdir=/mnt/layers/RAM/upper_changes,workdir=/mnt/layers/RAM/work)
/dev/sda3 on /mnt/layers/merged/mnt/sda3 type ext4 (rw,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
devtmpfs on /dev type devtmpfs (rw,nosuid,size=1549468k,nr_inodes=387367,mode=755,inode64)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,nodev,size=325344k,mode=755,inode64)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755,inode64)
cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=28,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=13300)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=325340k,mode=700,uid=1000,gid=1000,inode64)

[miltonx]

I read weedog initrd's init script, and found this line in w_init:

Code: Select all

mount -o mode=1777,nosuid,nodev${inram_sz} -n -t tmpfs inram ${layers_base}/RAM  # for w_changes=RAM;w_copy2ram

Seeing "nosuid,nodev" option when mounting w_changes, I thought maybe this caused the problem. So I removed "w_changes=RAM0" from the boot options. Rebooted into Ubuntu Kylin, and sudo works!

However, previously when making weedog debian and weedog bunsenlabs, I kept the "w_changes=RAM0" option, and sudo had no problem. Why for Ubuntu Kylin does it cause the "file system with the 'nosuid' option" error?

[wiak]

I read weedog initrd's init script, and found this line in w_init:

Code: Select all

mount -o mode=1777,nosuid,nodev${inram_sz} -n -t tmpfs inram ${layers_base}/RAM  # for w_changes=RAM;w_copy2ram

Seeing "nosuid,nodev" option when mounting w_changes, I thought maybe this caused the problem. So I removed "w_changes=RAM0" from the boot options. Rebooted into Ubuntu Kylin, and sudo works!

However, previously when making weedog debian and weedog bunsenlabs, I kept the "w_changes=RAM0" option, and sudo had no problem. Why for Ubuntu Kylin does it cause the "file system with the 'nosuid' option" error?

That's interesting. Alas, I have no idea why.

w_changes=RAM0

is used to store all changes in RAM only (i.e. no persistence - they are just stored there for that session only, though it would be possible to manually rsync or cp them out to external media for use on future reboot). Once small thing I'd try is to create an empty directory in your boot partition called upper_changes/ and then reboot with w_changes=RAM0 to see if that makes any difference. I doubt it will, but I've forgotten what that bit of the w_init code does so will have to re-investigate its operation. It is odd that sudo works fine with all distros I myself use no matter what w_changes mode I'm using, but not also with your Ubuntu Kylin, though I don't normally start my tests with w_changes=RAM0 (I usually start with no w_changes entry at all, which results in normal direct to boot directory upper_changes save folder persistence).

Prior to your immediate above post, I had written (what now seems irrelevant but useful in other circumstances), but your above post crossed in before I had time to send this anyway:

Hello miltonx,

WDL initrd simply allows you to set up layers and boot into whatever rootfilesystem you are using it with (in this case Ubuntu Kylin). It has no control itself over how Ubuntu Kylin sets up its passwords, so if sudo isn't working after logging in as Ubuntu Kylin official non-root user then WDL initrd cannot itself do anything about that. So what to do??? Well, I don't have Ubuntu Kylin so tricky to give any definite answer, but seems to me that Ubuntu's official initrd (initramfs) must have some code in it that alters the environment in such a way that sudo works after the switch_root to the main Ubuntu Kylin rootfilesystem. Whilst I suppose it 'might' after a lot of research be possible to duplicate that in a special WDL initrd (w_init), that would be a big job for you perhaps or for anyone else.

However, I imagine there is another, simpler way, at least this is what I would try in that situation:

Manually create a password for user root in the Ubuntu Kylin rootfilesystem you are using, prior to boot. To do that you need an uncompressed directory version of the Ubuntu Kylin rootfilesystem. Assuming it is currently called NNfirstrib_rootfs.sfs you would need to:

Code: Select all

unsquashfs NNfirstrib_rootfs.sfs

so that you end up with the uncompressed directory and rename it to say 08firstrib_rootfs/
At this stage we are going to use that directory rather than the .sfs version so you need to rename the NNfirstritb_rootfs.sfs to not start with a layer number (then it won't be used). For example, rename it DNNfirstrib_rootfs.sfs (any name will do as long as first character isn't a number).

The next part, setting root password, is something both rockedge and I often need to do with other created WDL firstrib rootfilesystems. We mount the uncompressed 08firstrib_rootfs/ and then set root user's password directly, which will later allow you to login as root (or at least, hopefully, su - to become root user after boot). WeeDogLinux provides two little utilities that make it a simple matter to chroot into the 08firstrib_rootfs directory to make any changes you with. These are mount_chroot.sh and umount_chroot.sh (the latter being used to clean up the chroot mounts once alterations you made have been completed).

You can download these mount_chroot.sh and umount_chroot.sh utilites from this post (remove the dummy .tar make them executable before use): viewtopic.php?p=37093#p37093

So to set a password for root user in the 08firstrib_rootfs/ directory run the command:

Code: Select all

./mount_chroot.sh 08firstrib_rootfs

At the # prompt which then appears, now enter command:

Code: Select all

passwd

followed by the password you want for root user (I suggest just using 'root' as the password, without the quotes of course).

After confirming root's password, you now leave the chroot shell by entering the command:

Code: Select all

exit

Finally, and this is an important step, you should 'clean up' the mounts that were used during the chroot. Fortunately that is simply a matter on now running the umount utility via terminal command:

Code: Select all

./umount_chroot.sh 08firstrib_rootfs

You should now try rebooting into your WDL Ubuntu Kylin and seeing if you can login (of su -) as user root. If so you can then fix sudo situation, perhaps by creating a new 'normal user' with wheel group rights (I can explain that later if all goes well logging in as 'root') or perhaps by assigning official Ubuntu Kylin normal user to that same 'wheel' group (that has sudo rights without needing extra password entry).

Let us know how above goes. Certainly, we should be able to succeed via this method though the process may need a few 'tweaks' in practice.

wiak

EDIT: Not sure when/if I'll get round to it, but I may try Ubuntu Kylin sometimes to see if I can get to the bottom of the issue you had. It does appear from what you say that Ubuntu has set up sudo differently where suid capable tmp directory is required(?)

[wiak]

NOTE:

https://unix.stackexchange.com/question ... -directory

Many systems use tmpfs for /tmp: a filesystem whose content remain in memory and isn't preserved on a reboot. (A tmpfs filesystem can be faster than relying on the disk cache because it doesn't need to care about data consistency.) Some setups mount it with the nosuid option, because there usually isn't any call for setuid temporary files and this could occasionally be part of an attack vector (setuid files in /tmp are not a security risk per se, but disabling them can limit the damage caused by a few vulnerabilities).

See also: https://ubuntu.com/blog/data-driven-ana ... p-on-tmpfs
https://www.techrepublic.com/blog/linux ... -in-linux/
https://help.ubuntu.com/community/RootSudo

I guess you could monitor /tmp (though just noticed this through browsing), but the issue may be related to some other directory that is set up in WDL to use tmpfs:

https://ubuntu.com/blog/spotting-tmp-re ... tmpwatcher

[wiak]

Probably irrelevant, but came across this also:

https://bugs.launchpad.net/ubuntu/+sour ... ug/1791241

After some research, I found that setting the environment variable TMPDIR to /tmp did the job for me

So sorry that overall I can't help you at this moment with this one. But if the issue keeps coming up I'll likely end up looking into it myself also.

I presume you have the 'sudo' command somewhere in the rootfilesystem and not added later to upper_changes in RAM. I think the latter would be an issue since my reading is that sudo will not work if run from a filesystem that is set as nosuid. I haven't come across this issue personally or before, but now you've brought it up I am wondering if updating sudo (when running with upper_changes in RAM) will result in the issue you are experiencing (since the updated sudo will be stored in that nosuid tmpfs upper_changes in RAM location (I'm not sure yet though).

EDIT: No. I updated sudo on my WDL_Arch64 system, such that the executable was in upper_changes, and I used w_changes=RAM1 mode which copies the external upper_changes into /mnt/layers/RAM/upper_changes and then uses the latter, but sudo continued to work fine on reboot. Alas I do not know what the difference is with your Ubuntu Kylin rootfilesystem. I will try is sometime, but don't know when (EDIT2: attempting to download Ubuntu Kylin now actually, but I only have very slow and not too reliable broadband so at best will take a long while downloading since 3.8GB...). Glad you found a way round it anyway since might prove useful in later tests.

[wiak]

I've now downloaded Ubuntu Kylin and tried WeeDogging it in a different way.

I clicked on the iso to open it and simply copied casper/filesystem.squashfs to 08filesystem.sfs in an empty WDL_UbuntuKylin directory.

Then I'm using the skeleton initrd along with rockedge's vmlinuz-5.4.70-fossapup64-rt40 and 00modules.sfs and 01firstrib_firmware.sfs. I'm doing it that way because I have very little space on my dev machine and easy and quick to try.

Well... that's boots up to a GUI login prompt but I can't find a user/password combination that lets me try further...

May be that I'll need to mount_chroot.sh into the 08filesystem.sfs to set up user/password unless you know a combination that 'may' work. Problem I have is that my harddrive space is too low to uncompress the squashfs and set up the passwords and its late at night here... I'll think about it tomorrow. May copy over to another machine I have and try there, but if you have a user/password combination for me to try that might save me doing that (but maybe won't work if Ubuntu usual install sets up the passwords during normal installation, which as I say I haven't done).

wiak

[miltonx]

... but if you have a user/password combination for me to try that might save me doing that ...
wiak

As I can recall, Ubuntu-Kylin, when booted live, does not have a password for the default user. I remember I could run "sudo..." without inputting any password when running it live.

Later I did a full install on usb (setting up my user and password), and copied all those installed files to my 01-ubuntu-kylin-installed folder for weedog.

Here is an important update about the nosuid thing:
I modified your w_init in the initrd, editing this line:

Code: Select all

mount -o mode=1777,nosuid,nodev${inram_sz} -n -t tmpfs inram ${layers_base}/RAM  # for w_changes=RAM;w_copy2ram

to

Code: Select all

mount -o mode=1777 -n -t tmpfs inram ${layers_base}/RAM  # for w_changes=RAM;w_copy2ram

By removing the "nosuid,nodev" options, the problem appears to be fixed. Now I can boot kylin with the w_changes=RAM0 option, and use "sudo".

I don't know whether removing "nosuid,nodev" would lead to any security concerns, but anyway, I'm using weedog and linux on my single-user machine.

I guess Ubuntu-Kylin has some weird mechanism which addes or modifies sudo-related files after booting, so that these files end up in the RAM0 part for changes, which is mounted as nosuid.

Another wild guess question is, does it have something to do with my machine's small memory size (4g ddr3)? Previously on weedog debian and weedog bunsenlabs, those systems are pretty lean and small, but Ubuntu-Kylin is way larger. Does that lead to some part of the file system being pushed to the nosuid mount part?

[rockedge]

I have the ISO 75% downloaded via torrent. These are the steps I will attempt using the same kernel 5.4.70-rt40 and the firmware and module squash files.
1. download and mount ISO
2. create frugal directory and decompress/mount and copy the contents of /casper/filesystem.squashfs to the empty directory /WDL-kylin/08firstrib_rootfs.
3. mount 08filesystem with mount_chroot.sh (IMPORTANT: use umount_chroot.sh to "unmount" the rootfs after exit.)

Code: Select all

./mount_chroot.sh 08firstrib_rootfs

4. here will be the methods I test out

[wiak]

Another wild guess question is, does it have something to do with my machine's small memory size (4g ddr3)? Previously on weedog debian and weedog bunsenlabs, those systems are pretty lean and small, but Ubuntu-Kylin is way larger. Does that lead to some part of the file system being pushed to the nosuid mount part?

No it doesn't.

[rockedge]

I got it to run and update. details coming. Basically decompressed the squash file made a directory and copied the contents. Used the mount script and used

Code: Select all

passwd
adduser weedog

then umount script.
When booting the login screen loads with "weedog" as the user. I used the password weedog setting up with adduser. The system logs in and is running! Nice so far. I tried out apt update in a terminal with sudo which updated the repos. I will need to add user weedog to the sudoer file.

Screenshot from 2021-10-05 17-23-16.png (548 KiB) Viewed 3337 times

[wiak]

I downloaded ubuntukylin-20.04-pro-amd64.iso

from https://www.ubuntukylin.com/downloads/s ... 51&lang=en

I hope this is the correct version...

https://www.ubuntukylin.com/news/showne ... 44&lang=en

It is very nice looking distro.

I WeeDogged it in similar (but slightly different) way to rockedge:

Clicked on the iso to open that up. Found filesystem.squashfs and copied that to empty WDL_UbuntuKylin directory.

Then I used unsquashfs filesystem.squashfs to uncompress it and simply renamed the unsquashed directory as 08filesystem/ ready for booting with WDL (actually you could save a bit more effort just renaming it something like 08squashfs-root, since directory squashfs-root/ is result of unsquashfs, and the name doesn't matter - only the two digit layer number in the front).

NOTE: rockedge's rt40 Puppy Linux huge kernel is available per his post here: viewtopic.php?p=37673#p37673
Before booting with rockedge's vmlinuz, 00modules.sfs (renamed from zdrv.sfs) and 01firstrib_firmware.sfs (renamed from fdrv.sfs), I created a weedog user and applied passwords using mount_chroot and umount_chroot scripts as follows:

Code: Select all

./mount_chroot.sh 08filesystem

I believe at that point I altered the PATH so /usr/sbin/visudo could be found:

Code: Select all

export PATH=$PATH:/usr/sbin

then I ran the commands:

Code: Select all

addgroup --system wheel
echo '%wheel ALL=(ALL) NOPASSWD: ALL' | (VISUAL="tee -a" visudo)
useradd -m -G wheel -s /bin/bash weedog
printf "weedog\nweedog" | passwd weedog >/dev/null 2>&1

and I also set a password for root user using command:

Code: Select all

passwd

and entering root as the password and confirmed that.

Then I exited the chroot using command:

Code: Select all

exit

Finally, I cleaned up the mount_chroot mounts using command:

Code: Select all

./umount_chroot.sh 08filesystem

I booted into the system and it automatically took me to weedog login screen and password 'weedog' worked. All fine thus far. I'm not sure about the sudo stuff above (still to test) - there are other ways of doing it rather than setting up a 'wheel' group (could likely just add weedog user to sudo group). Will come back about that once I've tested to see if working at all.

I note that WPS office suite is part of this Pro UbuntuKylin install. Peony is the filemanager, and uses Mate terminal. Very interesting distro indeed.

wiak

EDIT: Wifi connected fine, and I'm posting from it now (Firefox). I used its provided screenshot app but installed mtpaint to rescale the result.
EDIT2: I have now booted with w_changes=RAM0 mode and all was fine. sudo worked fine and I didn't need to modify w_init at all.

[miltonx]

Seeing that rockedge and wiak both used the live iso's squash file, I thought maybe my approach of using the fully-installed system files was problematic, so I followed your method, and unsquashed live iso's squash file into 01xxx folder, but the nosuid issue remains.

I tried both rockedge's and wiak's chroot and user creation procedures, following each step exactly, with the exception of kernel and initrd. I used kylin's built-in kernel (/boot/vmlinuz-5.10.0-1029-oem) and used wiak's modify_initrd_gz.sh & initrd_v400rc1.gz to make the initrd file (putting in kylin's /usr/lib/modules/5.10.0-1029-oem). I don not have 00modules and 01firmware.

Besides, I also found that my mount...sh & umount...sh are different from yours. I attached the version I used, which threw the following error, but still seemed to work when creating user.

Code: Select all

ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

The chroot scripts I used:

mount_chroot-latest.txt

(1.65 KiB) Downloaded 53 times

umount_chroot-latest.txt

(846 Bytes) Downloaded 50 times

So far, the only things I did differently from you are the kernel/initrd and mount/umount scripts. Can these cause the nosuid error?

[rockedge]

@miltonx I will also try out the Kylin kernel. What does your boot stanza look like?

This is what I am using:

Code: Select all

title WDL-kylin(uuid)
  uuid 8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa
  kernel /WDL-kylin/vmlinuz-5.4.70-rt40 w_bootfrom=UUID=8a8ea99d-a1b0-4c43-b1a0-d4ce5c9c7dfa=/WDL-kylin net.ifnames=0
  initrd /WDL-kylin/initrd_v401rc1.gz

And as noted I used the Puppy Linux huge kernel because I had them handy. But it does sound like you have the kylin kernel booted and you are connected to the network as well. The mount / umount scripts have been updated though I believe the versions you used should also work.

I have also run across the same error when working with building WDL-Void systems on FossaPup64. Sometimes this worked: (translated to Ubuntu speak)

Code: Select all

export LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
sudo apt install gtk3-nocsd

In my version running now I do not have this error nor this file but this fix seems to be another option if libgtk3-nocsd is installed.
edit: /etc/X11/Xsession.d/01gtk3-nocsd with :
uncomment and set to 1:

Code: Select all

export GTK3_NOCSD_IGNORE=1

Links to the scripts:
mount_chroot.sh
umount_chroot.sh

[wiak]

I weedogged Ubuntu Kylin 20.04 pro, which boots and runs fine. But whenever I run "sudo ...", occurs this error:

Code: Select all

sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

Actually I tried two methods of making weedog ubuntu-kylin, both resulting in the above.

I am just going out miltonx, but I will look at it again. I will also try the Kylin kernel/modules/firmware combination. The mount/umount scripts are not the cause of the sudo issue - nothing themselves to do with that; they are just simple utilities for modifying underlying contents of the rootfilesystem.

It's strange, because doing it the way I explained, which included the creation of user weedog and putting weedog into wheel group for sudo, sudo worked when I quickly tried it, both with empty w_changes and with w_changes=RAM0

I have in fact never seen the above 'effective uid is not 0' error you get. I cannot comment on the use of any normal user assigned by Ubuntu Kylin themselves - I don't have such. Rather I just have user WeeDog, which allowed me to do the likes of 'sudo vi' and also I assigned root the password 'root' so that worked as well as did:

Code: Select all

su -

as an alternative means of becoming root user.

I'm currently at a loss to understand the issue you are facing since I was unable to duplicate the error in my build arrangement.

What is the format (ext4 or whatever) of the underlying filesystem you have created the installation on?

Below is screenshot of me using sudo to start a root owned mate-terminal as user weedog, but this is with rockedge's kernel. Note was running in RAM using w_changes=RAM0

[miltonx]

What is the format (ext4 or whatever) of the underlying filesystem you have created the installation on?

The weedog-kylin folder is on an ext4 (sda3).
The full install I previously did was on an ext4 usb drive.

[miltonx]

Talking of puppy kernel, I now recall that I have also tried booting kylin with fossapup kernel and initrd. (this means I had to convert the 01xxx folder into puppy_fossapup64_95.sfs). Booted and was able to run sudo, though screen resolution appeared not right, but that is another topic.

However, puppy kernel+initrd set does not involve the w_changes=RAM0 option, so it's not really comparable.

I will try rockedge's method, using puppy kernel plus weedog skeleton initrd and 00modules & 01firmware.

[miltonx]

@miltonx I will also try out the Kylin kernel. What does your boot stanza look like?

These are the multiple boot entries:

Code: Select all

title ubuntukylin, iso sfs unsquashed, OEM kernel and modules, cannot sudo
  find --set-root --ignore-floppies /ubuntukylin-iso/initrd-nosuid.gz
  root (hd0,2)
  kernel (hd0,2)/ubuntukylin-iso/vmlinuz-5.10.0-1029-oem w_bootfrom=/mnt/sda3/ubuntukylin-iso w_changes=RAM0
  initrd (hd0,2)/ubuntukylin-iso/initrd-nosuid.gz

title ubuntukylin, iso sfs unsquashed, kylin's Generic kernel and modules, cannot sudo
  find --set-root --ignore-floppies /ubuntukylin-iso/initrd-nosuid-generic.gz
  root (hd0,2)
  kernel (hd0,2)/ubuntukylin-iso/vmlinuz-5.4.0-74-generic w_bootfrom=/mnt/sda3/ubuntukylin-iso w_changes=RAM0
  initrd (hd0,2)/ubuntukylin-iso/initrd-nosuid-generic.gz

title ubuntukylin, remove-nosuid (modified w_init), sudo fine
  find --set-root --ignore-floppies /ubuntukylin/initrd-remove-nosuid.gz
  root (hd0,2)
  kernel (hd0,2)/ubuntukylin/vmlinuz-5.10.0-1029-oem w_bootfrom=/mnt/sda3/ubuntukylin w_altNN=/mnt/sda3/ubuntukylin w_changes=RAM0
  initrd (hd0,2)/ubuntukylin/initrd-remove-nosuid.gz

title puppy kernel puppy initrd --> ubuntukylin, sudo fine, but screen resolution not right
  find --set-root --ignore-floppies /fossapup64/initrd.gz
  kernel /fossapup64/vmlinuz pmedia=usbflash pdev1=sda3 psubdir=ubuntukylin
  initrd /fossapup64/initrd.gz

[wiak]

Hello miltonx,

First the good news (but maybe shouldn't be called 'good'). I can confirm that with official Kylin kernel/modules sudo doesn't work with error message:

I weedogged Ubuntu Kylin 20.04 pro, which boots and runs fine. But whenever I run "sudo ...", occurs this error:

Code: Select all

sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?

Actually I tried two methods of making weedog ubuntu-kylin, both resulting in the above.

Yet, sudo works fine if using rockedge kernel/modules. Well, isn't that weird??? That's the bad news - I have no idea why a different kernel/modules combination would result in that effect. Your 'fix' was to turn off nosuid, so clearly that is a clue. Something about the Ubuntu Kylin kernel must be using that tmpfs for sudo (and that messes with sudo since won't run from nosuid filesystem...). I have no idea at this stage what Kylin kernel does differently to rockedge's. hmmm... interesting one - I will certainly look into it further, but I do not know much about sudo operation per se so not at all confident what I'm looking for. At least you have that nosuid 'fix', but I do find that unsatisfactory without us knowing why Ubuntu Kylin kernel proving so different to all other distros thus far WeeDogged.

If I find anything further I'll report back of course.

Note that a normal full Ubuntu Kylin install probably works fine since not using a nosuid overlay in that case anyway. I haven't tried it yet, but I imagine not using w_changes=RAM0 (or RAM1 or RAM2) will also work fine. i.e. try simply deleting w_changes=RAM0 from your grub kernel line and see if sudo works - that mode provides save persistence directly to boot directory upper_changes folder so pretty useful anyway.

EDIT: Yes, sudo works with the kernel if you don't run from RAM (i.e. delete w_changes=RAM0 from your grub kernel line). Or, as you say, remove the nosuid from the tmpfs memory creation. Don't know if we will find any other solution, but isn't it weird how rockedge's kernel/modules/firmware combination doesn't result in this issue at all?!!! I am suspecting some module or piece of firmware is not provided in rockedge's creation such that part of the sudo security system is not operational (but enough for sudo itself to be working), but again, I find that very peculiar and worth looking into further - though whether reason will be found is another matter...

wiak

[miltonx]

Hi, Wiak,

This aligns with my testing - sudo is working when w_changes is not set.

I removed w_changes parameter and booted kylin, found sudo working. Then I opened the upper_changes folder to investigate what changes occurred after booting. I found it contains /etc and /root folders, besides others. That means, kylin modifies these folders right after booting. And these modified folders probably contain something used by the sudo command, potentially landing up in a nosuid jail (if w_changes=RAM0 had been set).

And, @ Rockedge,

Your puppy giant kernel is very intetesting. Is it taken straight from fossapup, or does it need extra files to be added / compiled?

Edit:
I read previously posts and found https://rockedge.org/kernels Obviously the kernel is recomplied, and it is really "huge". I will try it.

Re-edit:
I downloaded the 5.4.70 kernel. It turns out to be a compressed package containing vmlinuz and modules / firmware. So the vmlinuz is not that huge. The question still is, is it taken from fossapup or is it somehow re-compiled?

P.S.
I used rockedge's huge kernel and zdrv fdrv files. Yes I can boot and can use sudo, but screen resolution is not right (probably due to my hardware). This is similar to when I used fossapup's vmluz and initrd (converting 01-kylin folder into an sfs file named "puppy_fossapup64_95.sfs".)

[wiak]

Here is an important update about the nosuid thing:
I modified your w_init in the initrd, editing this line:

Code: Select all

mount -o mode=1777,nosuid,nodev${inram_sz} -n -t tmpfs inram ${layers_base}/RAM  # for w_changes=RAM;w_copy2ram

to

Code: Select all

mount -o mode=1777 -n -t tmpfs inram ${layers_base}/RAM  # for w_changes=RAM;w_copy2ram

By removing the "nosuid,nodev" options, the problem appears to be fixed. Now I can boot kylin with the w_changes=RAM0 option, and use "sudo".

I don't know whether removing "nosuid,nodev" would lead to any security concerns, but anyway, I'm using weedog and linux on my single-user machine.

I guess Ubuntu-Kylin has some weird mechanism which addes or modifies sudo-related files after booting, so that these files end up in the RAM0 part for changes, which is mounted as nosuid.

I've tried many things since my last report, including mount remounting merged with suid, but none of that worked.

However, the more I think of it, I rather believe that the Ubuntu overlayfs is working more correctly in that when using w_changes=RAM0 the filesystem is indeed set as nosuid, which would indeed cause sudo to fail (which is not good of course). I have read that some people using docker containers have had similar issues but not when using aufs - apparently aufs is ignoring the suid, which makes me wonder if overlayfs is also ignoring the set nosuid in some implementations. It could be that Ubuntu have patched the overlayfs code such that nosuid is correctly being interpreted, in which case your above 'fix' is the best we can do.

My issue becomes whether I should adopt that removal of nosuid,nodev in main WDL initrd or leave it in (since same issue has occurred no where else thus far) and simply use the external w_init to 'fix' it in times of such trouble... For now, I'll leave it in and suggest having external w_init with the nosuid,nodev removed such that sudo works. I doubt any security issue is major enough to concern ourselves with... In fact I do suspect that I shouldn't have made that inram RAM area nosuid,nodev - I just blindly put these options in since was tmpfs, but for this use-case probably should be suid,dev instead... I'll consider that for later release.

Anyway, thanks for finding that; at least we know now how to get it working should similar issue crop up again when using one of the RAM modes. Of course there is no issue when not using RAM mode since non-RAM filesystem is not mounted as nosuid.

As for rockedge's kernel, I think he compiled that one himself, but it is like most Puppy kernels in that it is a 'huge kernel' meaning that it contains all the drivers needed to see the contents of media partitions. That allows us to use a separate modules and firmware addon (either uncompressed or as sfs files), which will be shared between the initrd and the main firstrib_rootfilesystem - that allows a big space saving since initrd can simply be the 640kB skeleton one for that case. Hence a nice way to build a really small WeeDog if we put our mind to that...

wiak

[miltonx]

As for rockedge's kernel, I think he compiled that one himself, but it is like most Puppy kernels in that it is a 'huge kernel' meaning that it contains all the drivers needed to see the contents of media partitions. That allows us to use a separate modules and firmware addon (either uncompressed or as sfs files), which will be shared between the initrd and the main firstrib_rootfilesystem - that allows a big space saving since initrd can simply be the 640kB skeleton one for that case. Hence a nice way to build a really small WeeDog if we put our mind to that...
wiak

Thanks for all the time, wiak! WDL is so addictive I can't help digging out more questions.

Regarding a huge kernel, I have also been thinking how to keep a skeleton initrd and to put all modules outside it, to save the trouble of decompressing/recompressing initrd for each distro. It's another topic, so that I will open another thread.

[wiak]

Regarding a huge kernel, I have also been thinking how to keep a skeleton initrd and to put all modules outside it, to save the trouble of decompressing/recompressing initrd for each distro. It's another topic, so that I will open another thread.

Yes, a huge kernel is indeed the answer to that. Another thread for that would indeed be good and rockedge can help you with that area. As far as nosuid is concerned, I've decided I've made a mistake there so will be removing nosuid,nodev (mount inram) from the future skeleton initrd release since for RAM layer overlay use sudo has to work of course!

[rockedge]

The question still is, is it taken from fossapup or is it somehow re-compiled?

I compiled the kernel from scratch. I used the kernel-kit and downloaded then applied the full real time patches for 5.4.70 which converts it to 5.4.70-rt40 and added the AUFS5 patches. Then I went through the configuration and set the necessary features. I have made several different versions of full real time huge kernels for Puppy Linux. I think they can all be used by WeeDog builds.

Some have the overlay module built in at compile time next to the AUFS5 patches.

I have used 5.4.70-rt40 in Tahr, Xenial, Bionic and Fossapup and in various variations of WeeDog.

5.4.70-rt40 is compiled on a Fossapup64-9.0.5 using the 4.19.82-rt30 kernel also available here -> https://rockedge.org/kernels/ or direct link -> 4.19.82-rt30

I originally made it for making electronic music using Puppy Linux as the platform. Some have used it to run CNC machinery with LinuxCNC with Puppy Linux as the OS.

[miltonx]

Thanks, rockedge. As I just came to read about the concept of huge kernel, I got curious how complicated this would be. Now this answers my question.

[rockedge]

@miltonx Give the kernel-kit a run and build a kernel! For an easy way to start is to go to woof-CE and clone a copy on your machine. Run ./merge2out and select the distro. This creates the woof-out directory. Go into the kernel-kit directory and open up the build.conf there fill in the values. Most simple is select a kernel version and the matching AUFS and run ./build.sh

This is of course a super simple explanation but sort of enough to start out experimenting.

To get an ideas of the kernel version numbers -> https://www.kernel.org/
The AUFS pages (look at the "branches" to find version numbers) -> https://github.com/sfjro/aufs5-standalone
The main AUFS Git repo -> https://github.com/sfjro/aufs5-linux
Real Time patches main page -> https://rt.wiki.kernel.org/index.php/Main_Page
The actual patches -> https://mirrors.edge.kernel.org/pub/lin ... ojects/rt/

Of course one can compile a kernel manually with out the kernel kit and apply the patches just as well but the kernel-kit can be manipulated to do most of the heavy lifting and is a really great way to get some experience.

I use the woof-CE "Testing" branch as well as the "master" branch for the kernel-kit.
After I am done using it I delete the woof-out directory since it does take up some room.

Another method it to use Github Actions to build a kernel version on the Git machines.

[miltonx]

This makes for some great reading! I will dig into it. Thanks!