Alexander Khryukin escreveu: > As pcpa suggested i removed > > if [ -f /etc/login.defs ] && ! grep -q USE_TCB /etc/login.defs; then > /usr/sbin/set_tcb --auto --migrate > fi > > > from pam spec. > > And now i got this > > > [root@bigbertha /]# useradd gg > configuration error - unknown item 'CRYPT_PREFIX' (notify administrator) > configuration error - unknown item 'CRYPT_ROUNDS' (notify administrator) > configuration error - unknown item 'USE_TCB' (notify administrator) > configuration error - unknown item 'TCB_AUTH_GROUP' (notify administrator) > configuration error - unknown item 'TCB_SYMLINKS' (notify administrator) > > > [root@bigbertha /]# groupadd sssff > configuration error - unknown item 'CRYPT_PREFIX' (notify administrator) > configuration error - unknown item 'CRYPT_ROUNDS' (notify administrator) > configuration error - unknown item 'USE_TCB' (notify administrator) > configuration error - unknown item 'TCB_AUTH_GROUP' (notify administrator) > configuration error - unknown item 'TCB_SYMLINKS' (notify administrator) > > > > [root@bigbertha /]# uname -a > Linux bigbertha.moondrake.org 3.8.0 #0 SMP Fri Jan 17 15:25:41 CET 2014 > aarch64 aarch64 aarch64 GNU/Linux
You mean it does not coredump anymore? I made a new pam build just to prevent anyone doing an innocent "urpmi pam" from breaking the system and not being able to login anymore without a lot of effort (systemd single user mode only allows login after root authentication...). > 2014-02-19 1:00 GMT+04:00 Alexander Khryukin <[email protected]>: > >> https://abf.io/build_lists/1645545 >> >> >> Child returncode was: 0 >> remove tree: /home/vagrant/tmpfs/openmandriva-2013.0-aarch64/root/builddir >> Executing command: ['/usr/sbin/userdel', '-r', '-f', 'mockbuild'] >> >> qemu: uncaught target signal 11 (Segmentation fault) - core dumped >> >> Child returncode was: -11 >> >> >> It's always segfault at useradd/groupadd command. >> I removed all OMV pam-related stuff include shadow-utils/pam/tcb/etc >> and installed same stuff from opensuse, and it's working fine without any >> segfaults. >> >> >> 2014-02-19 0:25 GMT+04:00 <[email protected]>: >> >> Denis Silakov escreveu: >>> > While this question is discussed - don't you want to consider complete >>> > switch from pam_tcb to pam_unix (as used in other distros) and from >>> > blowfish (iirc, it is still used for passwords in cooker) to sha? We >>> > performed such a move in ROSA not long ago, since it turned out that the >>> > old way doesn't integrate well with new Gnome. >>> >>> I was trying to collect some information, but my immediate goal is >>> to have things more stable. I restarted my cooker vm just to find out >>> I could no longer login, and took some time to figure it was caused >>> by a corrupted /etc/group, apparently due to a failed switch from >>> shadow to tcb. Checking logs, this was broken since 2008, but not >>> triggered because the main "pam" package was not being installed, >>> as installing "pam" causes "tcb" to be installed, and then stuff >>> breaks, badly. >>> >>> > Blowfish encryption seems to come from old MDV; not sure what was the >>> > reason for this, but this definitely decrease security. >>> >>> Someone with security background would be better to respond :-) >>> >>> > On 18.02.2014 21:55, [email protected] wrote: >>> >> While helping fedya to debug some problems in the aarch64 >>> >> chroot, I found that only mandriva* has this: >>> >> >>> >> $ rpm -q --scripts pam >>> >> [...] >>> >> if [ -f /etc/login.defs ] && ! grep -q USE_TCB /etc/login.defs; then >>> >> /usr/sbin/set_tcb --auto --migrate >>> >> fi >>> >> [...] >>> >> >>> >> note that also, from tested distros (well, suse and fedora) only >>> >> mandriva* has a USE_TCB string in /etc/login.defs, but the scriplet >>> >> is very naive, because the USE_TCB string in mandriva* is setting it >>> >> to "no" ... >>> >> >>> >> I think it is safe to match other distros and remove that scriptlet. >>> >> >>> >> pam_tcb is supposed to be an alternative to shadow, and that may >>> >> cause a lot of harm... >>> >> >>> >> This probably was also the reason I did need to fix my cooker vm >>> >> because /etc/shadow was corrupted, and all started, apparently >>> >> after forcing a rebuild of libutempter to "fix" dependency issues >>> >> generating a new chroot. >>> >> >>> >> For better archeology: >>> >> >>> http://svn.mandriva.com/viewvc/packages/cooker/pam/current/SPECS/pam.spec?view=annotate Thanks, Paulo
