Porteus-v5.01 bug reports

[Rava]

Hi Rava,
I builded onlyoffice-desktopeditors-7.5.0-x86_64-en-US.xzm only for English locale.

Thanks.
Since I still have the pseudo-installed files and folders it should be a piece of cake to add DE-de and EN-uk (or it is EN-gb?).

Is the md5sum correct?
8be2085cd1ba15ce89c3ed2d38691772

[nanZor]

MKSWAP bug in LXDE 5.01 ?

I followed the instructions in the FAQ to create a swapfile and when instructed to manually chown the file afterwards, the operation wasn't permitted and left the swapfile in an unsecure state. I performed this on a dedicated separate stick, not the boot stick.

Code: Select all

Creating empty file /mnt/sdc1/Porteus.swap, size 4000 MB
Formating the file with Linux Swap filesystem...
mkswap: /mnt/sdc1/Porteus.swap: insecure permissions 0777, fix with: chmod 0600 /mnt/sdc1/Porteus.swap

Here is what I keep running into. CHMOD works fine, but CHOWN does not. I tried both as guest and root:

Code: Select all

mkswap: /mnt/sdc1/Porteus.swap: insecure file owner 1000, fix with: chown 0:0 /mnt/sdc1/Porteus.swap

Here is the error:

Code: Select all

chown 0:0 /mnt/sdc1/Porteus.swap
chown: changing ownership of '/mnt/sdc1/Porteus.swap': Operation not permitted

So not mission-critical for me, but left me wondering why it won't let me chown as either guest or root.

(Note to self: when using a separate stick dedicated to a swapfile, and created after the fact, be prepared to change the device order in config for boot, and rc.local for swapon after reboot. (Either that or use uuid's.) Even while the order is now fixed, the warning comes up during boot that the swapfile is insecure.)

UPDATE: Fixed - thanks Rava!

[Rava]

I followed the instructions in the FAQ to create a swapfile and when instructed to manually chown the file afterwards, the operation wasn't permitted and left the swapfile in an unsecure state.

What kind of filesystem is your /mnt/sdc1/ ?
Permissions can only be set to a secure state when its a POSIX filesystem. Not NTFS or and kind of *FAT* (vfat, fat32, exfat etcetera)
Format your partition into ext[234] [ * ] and try again.

_________________
[ * ] ext[234] meaning here: either ext2 (no journaling, best for a thumbdrive), ext3 or ext4 (journaling, best for a harddrive or ssd)

[nanZor]

Thanks Rava! You are absolutely right. On this dedicated swap disk, I reformatted to EXT2 with a new swapfile and of course all those permission problems went away.

I was in a hurry and just started with a fat32 drive, which worked, but balked at permissions. But I wanted to do it right. I should have known.

As usual, thanks for your help!

[donald]

5.01 - xfce 4.16 > paper icon theme incomplete, even xzm modules
do not have 'their' icon.

[donald]

Nobody has an opinion of what I posted? -- again -- rc.FireWall:

Code: Select all

# ssh?
   $IPTABLES -A OUTPUT -p tcp --sport 1024:65535 -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT

Code: Select all

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    .......................          
    0     0 ACCEPT     icmp --  any    any     anywhere             anywhere             icmp echo-request
    0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere             tcp spts:1024:65535 state NEW,RELATED,ESTABLISHED

Which a) shouldn't be there if block all is chosen ( also icmp )
( it is applied to all, normal / strict / block all, firewall settings )

and b) does not make sense at all.What is this rule supposed to do?
There are rules for SSH if the firewall is in normal mode.

If you want to allow outgoing SSH connections — initiating an SSH connection to another server:
iptables -A OUTPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
should do it and start a SSH connection from within to the outside;
The input for SSH would be handled by the established / related rule.

However, I would like to not have that obscure rule in rc.FireWall (and the icmp one) if 'block all' is chosen.

EDIT
I know how to get rid of that.
What I'm talking about is it shouldn't be the defaults.

[Rava]

Nobody has an opinion of what I posted?

You meant the 5.01 - xfce 4.16 > paper icon theme incomplete part? I use the default icon dark theme (elementary xfce dark)
Could it be it was stripped too much?
Could a different version of 003-xfce contains the correct amount of icons for that theme?

I know how to get rid of that.
What I'm talking about is it shouldn't be the defaults.

What do you suggest be changed in rc.FireWall - probably with a bit of easy explanation for noobs or even for experienced Porteus users who are not that familiar with iptables.

[donald]

You meant the 5.01 - xfce 4.16 > paper icon theme incomplete part?

No,I meant this one:
Porteus-v5.01 bug reports (Post by donald #96131)

What do you suggest be changed in rc.FireWall - probably with a bit of easy explanation for noobs or even for experienced Porteus users who are not that familiar with iptables.

In simple words, we have firewall settings normal/strict/block all - every one with
their own amount of 'allowed ports'.

And then there is the # ssh? rule (posted above) applied to all of them,even to those
where ssh is not allowed eg.'block all' -- why?, and what is this rule good for?
Can someone explain it to me please?

Also (minor) icmp is allowed in 'block all'
In my book 'block all' has to block all except the absolute basic ALLOWED_PORTS="80 443"
for web browsing.

[Ed_P]

Code: Select all

guest@porteus:~$ su
Password: 
root@porteus:/home/guest# slapt-mod -u
/usr/local/bin/slapt-mod: line 34: [: gtk+3-3.24.33-x86_64-1: binary operator expected

[ncmprhnsbl]

thank you for your attention

And then there is the # ssh? rule (posted above) applied to all of them,even to those
where ssh is not allowed eg.'block all' -- why?

just an oversight, same with the icmp

and b) does not make sense at all.What is this rule supposed to do?
There are rules for SSH if the firewall is in normal mode.

If you want to allow outgoing SSH connections — initiating an SSH connection to another server:
iptables -A OUTPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
should do it and start a SSH connection from within to the outside;
The input for SSH would be handled by the established / related rule.

except what you posted doesn't appear to work, at least, not with the one sftp connection i use.. whereas the other one does.. don't remember where i found it :p, not saying there isn't a better way.

anyways.. here's a patch to try: firewall_patch.xzm
contains:

Code: Select all

firewall_patch
├── etc
│   └── rc.d
│       └── rc.FireWall
└── opt
    └── porteus-scripts
        └── gtk-firewall

changes:
no icmp, tcp(ssh?) with block all
icmp, tcp(ssh?) allowed with normal
only icmp allowed with strict
..didn't actually need to include rc.FireWall, didn't end up changing it

anything ipv6 remains unfinished, suggestions welcome

5.01 - xfce 4.16 > paper icon theme incomplete, even xzm modules
do not have 'their' icon.

partly why fulalas chose to use the elementary theme i presume.. xfce4 seems to be a bit strange with icons.. why it's not picking up the hicolor icon with Paper but does with elementary is a mystery to me.
a workaround for the xzm icon

Code: Select all

cd /usr/share/icons/Paper/32x32/mimetypes
ln -s /usr/share/icons/hicolor/32x32/mimetypes/cdr.png application-x-xzm.png

not seeing any others, what am i missing?

[jjr]

I should have linked this report here (in the official thread) with a TL;DR to respect others' time
[PATCH] Bug in finit prevents booting Porteus from alternative filesystems

tl;dr- there's an easily-verifiable syntax error in the Porteus initrd mount commands, which is prone to cause filesystem issues and prevents interoperability with macOS.

[Blaze]

it should be a piece of cake to add DE-de and EN-uk (or it is EN-gb?)

run as root

Code: Select all

update-onlyoffice

[donald]

....what you posted doesn't appear to work, at least, not with the one sftp connection i use..

I read in /etc/services sftp uses port 115 [standard but can be configured to use any I think]
....might be better to only open what you need and not the whole range of ports.

[Rava]

anyways.. here's a patch to try: firewall_patch.xzm
contains:

Code: Select all

firewall_patch
├── etc
│   └── rc.d
│       └── rc.FireWall
└── opt
    └── porteus-scripts
        └── gtk-firewall

changes:
no icmp, tcp(ssh?) with block all
icmp, tcp(ssh?) allowed with normal
only icmp allowed with strict
..didn't actually need to include rc.FireWall, didn't end up changing it

anything ipv6 remains unfinished, suggestions welcome

Is there an error with firewall_patch.xzm?
md5sum: bc7ac52b7cf445ad84810f977e5b6d49

I mloop'd the firewall_patch.xzm to compare the changes from the originals to be found in

Code: Select all

root@rava:/mnt/live/memory/images# find . -name rc.FireWall
./991-usr_local_bin_RECENT.xzm/etc/rc.d/rc.FireWall
./001-core.xzm/etc/rc.d/rc.FireWall
root@rava:/mnt/live/memory/images# find . -name gtk-firewall
./002-xorg.xzm/opt/porteus-scripts/gtk-firewall
root@rava:/mnt/live/memory/images# 

./991-usr_local_bin_RECENT.xzm/etc/rc.d/rc.FireWall are my changes for my email program to work.

After the mloop'ing of firewall_patch.xzm I compared the two files:

Code: Select all

root@rava:~# diff /mnt/loop/opt/porteus-scripts/gtk-firewall /mnt/live/memory/images/002-xorg.xzm/opt/porteus-scripts/gtk-firewall 
11,13d10
< icmp = '$IPTABLES -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT'
< sftp = '$IPTABLES -A OUTPUT -p tcp --sport 1024:65535 -m state --state ESTABLISHED,RELATED,NEW -j ACCEPT'
< 
141d137
<         run(['sed', '-i', 's/' + icmp + '/#' + icmp + '/g', '/etc/rc.d/rc.FireWall'])
143d138
<         run(['sed', '-i', 's/' + sftp + '/#' + sftp + '/g', '/etc/rc.d/rc.FireWall'])
152,153d146
<         run(['sed', '-i', 's/#' + icmp + '/' + icmp + '/g', '/etc/rc.d/rc.FireWall'])
<         run(['sed', '-i', 's/' + sftp + '/#' + sftp + '/g', '/etc/rc.d/rc.FireWall'])
162,163d154
<         run(['sed', '-i', 's/#' + icmp + '/' + icmp + '/g', '/etc/rc.d/rc.FireWall'])
<         run(['sed', '-i', 's/#' + sftp + '/' + sftp + '/g', '/etc/rc.d/rc.FireWall'])
root@rava:~# 

gtk-firewall differs okay, but should rc.FireWall from firewall_patch.xzm really be the very same as the version from Porteus 5.01 001-core.xzm?

Code: Select all

root@rava:~# diff /mnt/loop/etc/rc.d/rc.FireWall /mnt/live/memory/images/001-core.xzm/etc/rc.d/rc.FireWall 
root@rava:~# md5sum /mnt/loop/etc/rc.d/rc.FireWall /mnt/live/memory/images/001-core.xzm/etc/rc.d/rc.FireWall 
b53d78fdcbb435b0dac5accbb87d2e36  /mnt/loop/etc/rc.d/rc.FireWall
b53d78fdcbb435b0dac5accbb87d2e36  /mnt/live/memory/images/001-core.xzm/etc/rc.d/rc.FireWall
root@rava:~# 

[ncmprhnsbl]

might be better to only open what you need and not the whole range of ports.

firewall_patch.xzm?

revised firewall patch: firewall_patch.xzm md5sum: f1388695aa38883bfc5aef3442ae769d
changes:
removed the # ssh? section in rc.FireWall and corresponding parts in gtk-firewall. and leave it up to the user to enable the required port for the particular use case.
if you already use a custom rc.FireWall, be sure to compare and combine.
thank you to donald for your insights

now, sensible rules for ipv6 and then port the whole thing to nftables