On Fri, 12 May 2017 23:02:25 +0900 Florian Schaefer <[email protected]> said:
> On 12.05.2017 18:28, Carsten Haitzler (The Rasterman) wrote: > > On Fri, 12 May 2017 10:41:30 +0900 Florian Schaefer <[email protected]> > > said: > > > >> On 11.05.2017 22:12, Carsten Haitzler (The Rasterman) wrote: > >>> On Thu, 11 May 2017 21:07:20 +0900 Florian Schaefer <[email protected]> > >>> said: > >>> > >>>> > >>>> On 11.05.2017 12:33, Carsten Haitzler (The Rasterman) wrote: > >>>>> On Wed, 10 May 2017 09:48:19 +0200 PaulTT <[email protected]> said: > >>>>> > >>>>>> i just posted a message about this... (sorry, i've seen now this > >>>>>> thread) > >>>>>> > >>>>>> as i said there, there's also a problem with unlocking (so, pam > >>>>>> related, i assume ?) > >>>>>> via console su and sudo worked like a charm (i've got error messages > >>>>>> about cpufreq and backlight too) > >>>>> > >>>>> pam would be executing a setuid root binary to do the password check... > >>>>> so it's the same issue. something has decided that e and app processes > >>>>> below it in the process tree "cant run setuid (root) binaries" and has > >>>>> disabled that feature. that feature seems to only kick in with 4.11 > >>>>> kernel. it certainly is not e doing this. it has relied on this working > >>>>> for many years. it's something new security-wise that is being enabled > >>>>> by a new kernel. > >>>>> > >>>>> maybe some parent process is using setpriv? CAP_SETUID disabled? man > >>>>> capabilities ... for info ... maybe run captest ? > >>>>> e > >>>>> 12:20PM ~ > captest > >>>>> User credentials uid:1000 euid:1000 suid:1000 > >>>>> Group credentials gid:1000 egid:1000 sgid:1000 > >>>>> Current capabilities: none > >>>>> securebits flags: none > >>>>> Attempting direct access to shadow...FAILED (Permission denied) > >>>>> Attempting to access shadow by child process...FAILED > >>>>> Child User credentials uid:1000 euid:1000 suid:1000 > >>>>> Child Group credentials gid:1000 egid:1000 sgid:1000 > >>>>> Child capabilities: none > >>>>> Child securebits flags: none > >>>>> > >>>>> is what i get. which is normal. > >>>> > >>>> I get the same as you on my system here: > >>>> > >>>> florian@washu:~ # uname -a > >>>> Linux washu 4.11.0 #2 SMP PREEMPT Tue May 2 12:12:51 JST 2017 i686 > >>>> GNU/Linux florian@washu:~ # captest > >>>> User credentials uid:500 euid:500 suid:500 > >>>> Group credentials gid:100 egid:100 sgid:100 > >>>> Current capabilities: none > >>>> securebits flags: none > >>>> Attempting direct access to shadow...FAILED (Permission denied) > >>>> Attempting to access shadow by child process...FAILED > >>>> Child User credentials uid:500 euid:500 suid:500 > >>>> Child Group credentials gid:100 egid:100 sgid:100 > >>>> Child capabilities: none > >>>> Child securebits flags: none > >>> > >>> try capsh --print > >>> ? > >>> Current: = > >>> Bounding set > >>> =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read > >>> Securebits: 00/0x0/1'b0 secure-noroot: no (unlocked) > >>> secure-no-suid-fixup: no (unlocked) > >>> secure-keep-caps: no (unlocked) > >>> uid=1000(raster) > >>> gid=1000(raster) > >>> groups=5(tty),6(disk),7(lp),10(wheel),50(games),78(kvm),90(network),91 > >>> (video),92 (audio),93(optical),94(floppy),95(storage),96(scanner),98 > >>> (power),100(users),492 (oprofile),1000(raster) > >> > >> Oh, that's a nice command. :-) > >> > >> florian@washu:~ # /sbin/capsh --print > >> Current: = > >> Bounding set > >> =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read > >> Securebits: 00/0x0/1'b0 > >> secure-noroot: no (unlocked) > >> secure-no-suid-fixup: no (unlocked) > >> secure-keep-caps: no (unlocked) > >> uid=500(florian) > >> gid=100(users) > >> groups=20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46 > >> (plugdev),100(users),106(camera),108(netdev),119(systemd-journal) > >> > >> It seems that I have cap_setuid. That's good, right? > > > > yes you do... then that's odd. capabilities at least SAY they are allowing > > setuid... you are running this under e in some terminal... right? > > Yes. This is the output captured from terminology. The same terminology > that later won't be able to exec setuid stuff... well i'm fresh out of ideas.... it's obviously something shiny and new in 4.11 that i have yet to ever hear of or see myself. (i'm still on 4.10 here). what shiny new thing it is... that is the question -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
