36064 2019-02-08 15:27:05 +0300 su doesn't work in hasher 2019-02-12 04:40:01 +0300 1 1 4 Development Sisyphus branding-xalt-kworkstation-release unstable all Linux CLOSED FIXED P3 normal --- 1 imz zerg iv ldv zerg qa-sisyphus oldest_to_newest 178378 0 imz 2019-02-08 15:27:05 +0300 hasher-priv-1.5.2-alt1.x86_64 hasher-1.3.35-alt1.noarch su-0.60-alt35.x86_64 su doesn't work in hasher anymore. [root@localhost .in]# su -l nobody -s /bin/sh -c pwd <86>Feb 8 12:23:11 su[32381]: pam_tcb(su:session): Session opened for nobody by caller(uid=0) <83>Feb 8 12:23:11 su[32381]: pam_limits(su:session): Could not set limit for 'nproc': Operation not permitted su: Permission denied [root@localhost .in]# su <86>Feb 8 12:23:13 su[32383]: pam_tcb(su:session): Session opened for root by caller(uid=0) <83>Feb 8 12:23:13 su[32383]: pam_limits(su:session): Could not set limit for 'nproc': Operation not permitted su: Permission denied Sometimes, there are similar messages about "memlock" and not "nproc". 178405 1 iv 2019-02-09 09:16:55 +0300 (In reply to comment #0) > hasher-priv-1.5.2-alt1.x86_64 > hasher-1.3.35-alt1.noarch > su-0.60-alt35.x86_64 > > su doesn't work in hasher anymore. > > [root@localhost .in]# su -l nobody -s /bin/sh -c pwd [...] It works on my machine; versions of hasher, hasher-priv and su are the same. [root@localhost .in]# su -l nobody -s /bin/sh -c pwd <86>Feb 9 06:03:05 su[13764]: pam_tcb(su:session): Session opened for nobody by (uid=0) su: wtmp open: No such file or directory /var/nobody <86>Feb 9 06:03:05 su[13764]: pam_tcb(su:session): Session closed for nobody [...] > <83>Feb 8 12:23:11 su[32381]: pam_limits(su:session): Could not set limit for > 'nproc': Operation not permitted Probably nproc an memlock limits on your machine are stricter than the defaults. I can easily break su in hasher by setting, for example, nproc limit to some smaller value: [10:06:45 ~]$ ulimit -u 512 [10:06:49 ~]$ hsh-shell -q --rooter [root@localhost .in]# su -l nobody -s /bin/sh -c pwd <86>Feb 9 06:06:59 su[13922]: pam_tcb(su:session): Session opened for nobody by (uid=0) <83>Feb 9 06:06:59 su[13922]: pam_limits(su:session): Could not set limit for 'nproc': Operation not permitted su: Permission denied [root@localhost .in]# So, why such liberal limits are configured for the hasher chroot? For one, they are set in /etc/security/limits.d/90-desktop.conf: [root@localhost .in]# cat /etc/security/limits.d/90-desktop.conf # better defaults for desktop systems * soft nproc 4096 * hard nproc 5120 * soft nofile 8192 * hard nofile 10240 * soft memlock 1024 * hard memlock 2048 [root@localhost .in]# rpm -qf /etc/security/limits.d/90-desktop.conf pam-limits-desktop-0.1-alt2.noarch And it gets into the chroot because of branding: [root@localhost .in]# rpm -e pam-limits-desktop error: Failed dependencies: pam-limits-desktop is needed by (installed) branding-xalt-kworkstation-release-8.3.0-alt2.noarch I'm not sure what should we do about this. 178474 2 repository-robot 2019-02-12 04:40:01 +0300 branding-xalt-kworkstation-8.3.0-alt3 -> sisyphus: Mon Feb 11 2019 Sergey V Turchin <zerg at altlinux dot org> 8.3.0-alt3 - remove requires to pam-limits-desktop (ALT#36064)