https://bugzilla.suse.com/show_bug.cgi?id=1194945
Bug ID: 1194945
Summary: Cifs `umount` returns 32 and `df` fails with no
permission
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.2
Hardware: Other
OS: openSUSE Leap 15.2
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Kernel
Assignee: kernel-bugs(a)opensuse.org
Reporter: mantel(a)pre-sense.de
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Created attachment 855424
--> https://bugzilla.suse.com/attachment.cgi?id=855424&action=edit
cifs kernel debug output
Hello!
We have encountered two CIFS-issues which appear reproducible. But the
conditions
to reproduce are unknown to us. The setup is the following:
- An linux client which mounts a cifs share.
- Windows Server which offers the cifs share. Sadly, we could not determine
which windows server versions are related in the bugs.
- The cifs share contains subfolders for various users, which are readable
for the users.
- The parent folder is readable, but not writable for the users.
- Example: //domain_name/company_users/username
- company_users is a directory. the user has readonly permissions on that
directory.
- username is a subdirectory of company_users. the user has write
permissions on that directory.
We encounter two CIFS-issues. They might be considered as two seperate bugs,
but since
they occur in the same setup I just list them here:
- `df` fails with permission denied when using it on the share.
- `umount` of a cifs share fails with status code 32. Before the update to
openSUSE Leap 15.2 the umount operation worked. It seems to be a regression.
We could determine the kernel version which introduced the `umount` regression:
ok 5.3.18-lp152.63.1
ok 5.3.18-lp152.66.2
ok 5.3.18-lp152.69.1 --> last kernel which can umount
FAIL 5.3.18-lp152.72.1
FAIL 5.14.15-lp153.2.1.g3416a5a
In an upstream forum was a description for enhanced debug informations of the
kernel. You
can find enhanced debug output in an attached file, at the end of the file
(lines 721 - 739).
You can also find the `df` permission denied at line 422. We dont know this is
an actual regression. Every kernel we tried from openSUSE Leap 15.2 didn't
work.
We would like to debug this more but we have no clue how to continue at this
point.
Any help is welcome.
Thanks, Alex
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1186365
Bug ID: 1186365
Summary: Empty screen on Live XFCE in QEMU with virgl
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.3
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Xfce
Assignee: bnc-team-xfce(a)forge.provo.novell.com
Reporter: arvidjaar(a)gmail.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
I observed this both with Leap 15.3 current image and with Tumbleweed.
I boot manually using
"${QEMU_BIN}" \
-nodefaults \
-machine q35,accel=kvm \
-cpu kvm64 \
-m 2G \
-device virtio-scsi-pci \
-drive
file=$HOME/tmp/openSUSE-Leap-15.3-XFCE-Live-x86_64-Build9.78-Media.iso,if=none,id=cd0,format=raw
-device scsi-cd,drive=cd0,id=cd0 \
-netdev user,id=uplink -device virtio-net-pci,netdev=uplink \
-name "Leap 15.3 Live XFCE" \
-monitor unix:path="$QEMU_MONITOR_SOCKET",server=on,wait=off \
-vga virtio -display gtk,gl=on,zoom-to-fit=off,show-cursor=on \
&
It boots and leaves me with empty screen. Switching to tty1 and logging in I
see full graphical session correctly started, all processes present, just no
output on tty7. This works if I disable OpenGL (-display gtk,gl=off).
The KDE Live image boots normally using the same command line. TW XFCE Live
image has the same issue. Regular TW GNOME and KDE both work with virgl.
Host - Ubuntu 20.04 with GNOME Wayland session.
QEMU emulator version 6.0.0 (v6.0.0-1-gd11fb9fde1)
virglrenderer-0.7.0-1138-g3639155
Both compiled from source. QEMU has single patch to fix mouse positioning in
gtk under Wayland.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1193984
Bug ID: 1193984
Summary: SELinux: targeted: rpcinfo violation
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.3
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Other
Assignee: screening-team-bugs(a)suse.de
Reporter: okir(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
This is with Leap 15.3 and the targeted SELinux policy from MicroOS 5.1
This is a two-node configuration. Running rpcinfo on the client, trying to
perform a NULL call to the server's rpcbind:
/sbin/rpcinfo -T udp $server_ip portmapper
The test user is tied to SELinux user staff_u.
This results in the following audit message:
audit: type=1400 audit(1640160326.582:12): avc: denied { name_bind } for
pid=4754 comm="rpcinfo" src=690 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023
tcontext=system_u:object_r:hi_reserved_port_t:s0 tclass=udp_socket permissive=1
It's possible that this is harmless (rpcinfo may just try to do a
bindresvport() call in case it's running with privileges). However, in order to
avoid noise, we may want to patch this out for euid != 0.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1195904
Bug ID: 1195904
Summary: SELinux: targeted: ssh violation
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.3
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: screening-team-bugs(a)suse.de
Reporter: okir(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
The following happens with the SELinux packages from MicroOS 5.1 on SLES15SP3.
User "testuser" has been assigned SELinux user user_u and attempts to log in
via ssh, using key authentication
TEST: verify that the SSH key we generated can be used for authentication
== Authorizing ssh key id_rsa ==
client: echo $HOME; user=testuser
client: downloading /home/testuser/.ssh/id_rsa.pub
server: mkdir -m 0755 -p ~/.ssh; user=testuser
server: uploading data to /home/testuser/.ssh/authorized_keys
client: ssh -oStrictHostKeyChecking=no server true; user=testuser
Warning: Permanently added 'server,192.168.121.205' (ECDSA) to the list of
known hosts.
Failing: server: SELinux policy violation
server: by systemd (pid=4281; context=user_u:user_r:user_t:s0; permissive=1)
server: create access to dir inaccessible (dev=None; ino=None;
context=system_u:object_r:user_tmp_t:s0)
server: create access to file reg (dev=None; ino=None;
context=system_u:object_r:user_tmp_t:s0)
server: create access to fifo_file fifo (dev=None; ino=None;
context=system_u:object_r:user_tmp_t:s0)
server: create access to sock_file sock (dev=None; ino=None;
context=system_u:object_r:user_tmp_t:s0)
server: create access to lnk_file .#invocation:dbus.socketbf6abda56b666fe5
(dev=None; ino=None; context=system_u:object_r:user_tmp_t:s0)
OK, RSA key authentication seems to work
FAIL: server: SELinux policy violation
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1189907
Bug ID: 1189907
Summary: gnome-software: packages from the main distro
repository should not be marked as potentially
dangerous
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: GNOME
Assignee: gnome-bugs(a)suse.de
Reporter: mrueckert(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
it should work more like software.o.o categorizes packages.
i think the main culprit might be that it doesnt have any permissions
information like it has for flatpak based apps.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1172650
Bug ID: 1172650
Summary: MicroOS: License not displayed in german
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: screening-team-bugs(a)suse.de
Reporter: axel.braun(a)gmx.de
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
Created attachment 838577
--> http://bugzilla.opensuse.org/attachment.cgi?id=838577&action=edit
empty license screen
When installing MicroOS (snapshot:20200604) in german, the installation page
'Language, Keyboard and license contains am empty license
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1194705
Bug ID: 1194705
Summary: [SELinux] Problems with colord
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Security
Assignee: security-team(a)suse.de
Reporter: mcepl(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
See what I���ve found in the journal:
Jan 14 17:11:08 stitny colord[19334]: CdMain: failed to load mapping database:
Can't open database: unable to open database file
Jan 14 17:11:08 stitny systemd[1]: colord.service: Main process exited,
code=exited, status=1/FAILURE
Jan 14 17:11:08 stitny systemd[1]: colord.service: Failed with result
'exit-code'.
Jan 14 17:11:08 stitny systemd[1]: Failed to start Manage, Install and Generate
Color Profiles.
Jan 14 17:11:08 stitny kernel: audit: type=1400 audit(1642176668.663:44015):
avc: denied { read write } for pid=19334 comm="colord" name="mapping.db"
dev="nvme0n1p2" ino=14847 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:colord_var_lib_t:s0 tclass=file permissive=0
Jan 14 17:11:08 stitny kernel: audit: type=1400 audit(1642176668.663:44016):
avc: denied { read } for pid=19334 comm="colord" name="mapping.db"
dev="nvme0n1p2" ino=14847 scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:colord_var_lib_t:s0 tclass=file permissive=0
Using colord-1.4.5-4.2.x86_64 and selinux-policy-20211111-1.2.noarch
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1190847
Bug ID: 1190847
Summary: gparted shows suse-specific "type" flag
Classification: openSUSE
Product: openSUSE Tumbleweed
Version: Current
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Basesystem
Assignee: screening-team-bugs(a)suse.de
Reporter: aschnell(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
gparted shows the suse-specific "type" flag for partitions of an
MS-DOS label. Trying to unset the flag results in an error popup
followed by a crash.
The problem does not happen when installing upstream (lib)parted.
So likely the "type" patch for our parted should be improved. The
"type" flag also does not behave like the other flags.
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1173619
Bug ID: 1173619
Summary: VUL-0: unbound: LPE from unbound to root
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.1
Hardware: Other
OS: Other
Status: NEW
Severity: Normal
Priority: P5 - None
Component: Security
Assignee: darin(a)darins.net
Reporter: wolfgang.frisch(a)suse.com
QA Contact: qa-bugs(a)suse.de
Found By: ---
Blocker: ---
via security(a)suse.de:
I believe to have found a configuration issue in the Unbound package.
Or, depending on how you look at it, in the Unbound server itself.
1. Before starting the Unbound server, systemd routinely runs unbound-anchor.
From 'systemctl cat unbound':
ExecStartPre=/usr/bin/sudo -u unbound /usr/sbin/unbound-anchor -a
/var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem
As you can see this process is run as user unbound.
2. The Unbound server writes a pid file before dropping privileges, i.e. as
root. It then chown's the file in a second step.
'grep username /etc/unbound/unbound.conf':
username: "unbound"
And from the Unbound source:
https://github.com/NLnetLabs/unbound/blob/2a90e8fa1e22aa75d1cf67a1f71ebbf3f…
As you can see in the source, Unbound doesn't check if there is already a
symbolic link in place of the
pid file.
3. openSUSE configures Unbound to create the pid file in a directory owned by
the unbound user.
'grep pidfile /etc/unbound/unbound.conf':
pidfile: "/var/run/unbound/unbound.pid"
'cat /usr/lib/tmpfiles.d/unbound.conf':
D /run/unbound 0755 unbound unbound -
4. unbound-anchor is a nice little "do-one-thing-and-do-it-right" tool.
But if it is compromised, and as it has write permission in the pid file
directory and reliably runs before the server,
an attacker could easily gain full root privileges by just creating a
symbolic link /run/unbound/unbound.pid.
5. IMHO this would be best fixed in openSUSE by creating a root owned
/run/unbound directory,
or changing the pid file path to /run/unbound.pid or something like that.
I think this would have the added advantage that openSUSE could ship and
maybe enforce the Unbound AppArmor profile used in Debian and Ubuntu:
https://gitlab.com/apparmor/apparmor-profiles/-/blob/master/ubuntu/20.04/us…
With the current openSUSE setup there is the problem that if AppArmor
filters CAP_DAC_OVERRIDE, Unbound has no permission
to create a pid file in /run/unbound anymore.
If you have questions please don't hesitate to contact me.
Thanks for taking a look.
Kind regards,
Detlef
--
You are receiving this mail because:
You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1196224
Bug ID: 1196224
Summary: User Kerberos Tickets are not refresh or get destroyed
after Update to samba 4.15.4
Classification: openSUSE
Product: openSUSE Distribution
Version: Leap 15.3
Hardware: x86-64
OS: openSUSE Leap 15.3
Status: NEW
Severity: Critical
Priority: P5 - None
Component: Samba
Assignee: samba-maintainers(a)SuSE.de
Reporter: andreas.hauffe(a)tu-dresden.de
QA Contact: samba-maintainers(a)SuSE.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Firefox/91.0
Build Identifier:
At the end of January there was an update of Samba 4.13 to 4.15. Since this
time all our clients, which are Windows-AD members, doesn't keep the user
kerberos tickets like before. Either the tickets are not refreshed or the
tickets are destroyed. This results in a crashed KDE Plasma in the morning when
the users try to login again, since the clients/user accounts weren't able to
write on the kerberized NFS-Home mounts after the tickets got lost.
Reproducible: Always
Steps to Reproduce:
1. Configure PAM-Winbind for User logins
2. Wait some hours and the user tickets are not in the ticket cache any more
Actual Results:
Crashed KDE Plasma due to unwriteable home mounts
Expected Results:
refreshed user tickets in the ticket cache
smb.conf
[global]
netbios name = ilr114l
security = ADS
workgroup = ILRW
realm = ILRW.ING.DOM.TU-DRESDEN.DE
dedicated keytab file = /etc/krb5.keytab
kerberos method = secrets and keytab
template homedir = /home/home_ilrw/%U
template shell = /bin/bash
winbind refresh tickets = yes
winbind separator = +
idmap config * : backend = tdb
idmap config * : range = 2000-2999
idmap config ILRW : backend = rid
idmap config ILRW : range = 3000-9999 # UID aus RID fuer ILRW
idmap config DOM : backend = rid
idmap config DOM : range = 10000-9999999 # UID aus RID fuer DOM
krb5.conf
[libdefaults]
default_realm = ILRW.ING.DOM.TU-DRESDEN.DE
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
[realms]
ILRW.ING.DOM.TU-DRESDEN.DE = {
auth_to_local =
RULE:[1:$0@$1](ILRW\.ING\.DOM\.TU-DRESDEN\.DE@.*)s/\.ING\.DOM\.TU-DRESDEN\.DE@/+/
auth_to_local =
RULE:[1:$0@$1](DOM\.TU-DRESDEN\.DE@.*)s/\.TU-DRESDEN\.DE@/+/
auth_to_local = DEFAULT
}
--
You are receiving this mail because:
You are on the CC list for the bug.