17:45:09 [illumos-gate] 16626 sockfs: 'save_so_backlog' may be used uninitialized -- Toomas Soome 19:00:05 Can anyone remind me how /etc/security/exec_attr gets updated from the exec_attr.d/* files? 19:06:34 are you sure it does? I would guess they are just merged 19:10:45 yeah, looking at usr/src/lib/nsswitch/files/common I'm not seeing anything that'd look in the *.d dirs, suggesting something (maybe pkg?) has to be merging those into a single file 19:16:05 smells a bit like unfinished change from fork time... "Support for /etc/security/exec_attr.d/ files was added in Oracle Solaris 11.0.0." 19:16:15 https://docs.oracle.com/cd/E88353_01/html/E37852/exec-attr-5.html 19:48:07 And if I want to award privileges (proc_lock_memory) to a specific program, does that mean I have to run it with pfexec to make those privileges available to the process? 19:49:43 if it's privileges (and not authorizations), ppriv(1) should do that 19:50:26 (and of course you can specify all of that in an smf manifest if it's meant to be a service) 19:50:59 but if you want to 'allow non-priv user to run this', then yeah, i think pfexec would do it as well 19:51:27 Hm. Ideally want it to be just grated to this program, for whoever runs it. 19:51:48 then yeah, i think exec_attr + pfexec would do it 19:52:18 or i think if you use pf{bash,ksh,...} that might also do it automatically for you (but not 100% sure on that one) 19:52:50 Wish we didn't need the pfexec. Not sure how to get that when I run it under gdb. 19:54:58 i suppose something could be written that'd use extended attributes to hold the info, though then the trick is when/how to know when you can trust that data to avoid priv escalation 19:56:51 pfshells do the same as pfexec -- thats part of how you set up the role, as role is user type change and profile shell and assigned authorizations + profiles. 19:59:03 pfexec essentially is a tool to avoid to update your app code 20:01:48 so, it means, you can start pfbash, and use gdb from it without the need to use pfexec with your program you are debugging. 20:08:34 pf* works via pfexecd and magic 20:08:45 in theory, ln -s $(which gdb) pfgdb will do what you think it will 20:09:50 that too, yes:D 20:11:20 Really? pfgdb? I'll try :) 20:14:17 Hm. ppriv says just plain old basic 20:28:26 It would be cool if there were a way to mark an executable such that exec would do pfexec work. 20:28:44 Something like "wants pfexec" 20:30:29 that's what pfexecd does 20:30:32 suid? 20:31:17 but I'm not sure what it's doing to you instead 20:31:46 pfgdb crontab did list root crontab when I did "run -l root", but I was needing Cron Management profile to my user and gdb was unable to control crontab process, as gdb was run unprivileged and crontab was run euid=0 20:33:41 as I have sys_mount added to my user, ppriv run with gdb pid (run as pfgdb), does list sys_mount 20:35:02 so, if the command has privileges set via exec_attr, you would need the profile configured with your user. 20:48:17 I'm pretty sure I typoed in the command, and the link should have gone to pfexec not the normal gdb 20:48:28 and I think toomas has read what I meant to type and tried that :) 20:48:58 so a hardlink pfgdb -> pfexec 20:49:02 yes, you link with pfexec (similar as with isaexec) 20:49:03 cf. pfbash's inode and pfexec's 20:49:13 sorry my brain is a black hole 20:52:00 I guess I have instructed too many of the solaris sysadmin trainings:D some things do come without thinking;) 22:14:37 gwr: If you update the contents of files in /etc/security/exec_attr.d you need to restart the svc:/system/rbac:default service, which I believe merges the files into /etc/security/exec_attr 22:15:53 Thanks. 22:16:14 (packages that deliver files in there also must deliver an actuator to restart that FMRI etc) 22:17:22 gwr: Also, if you want to do something automatic with privileges, look at, e.g., "rsh" and the "Forced Privilege" profile 22:18:03 rsh is setuid root in the filesystem, but because it has a "Forced Privilege" entry in exec_attr it only gets "net_privaddr", not uid=0 23:11:07 it is inscrutable, but very cute 23:11:16 compared to modifying every piece of software 23:13:53 I wonder if anything cares about the "sticky" bit on files anymore? Maybe that could trigger pfexec actions on exec? 23:16:47 gwr, if i understand you correctly, what you want to do is that an unprivileged user can run a binary with a limited set of "privileged" extras 23:17:18 that's exactly what forced priv that jclulow mentioned does, or what a pf* link etc would do 23:17:21 we ship a few binaries in omnios where we do exactly that. set suid then limit what they can do 23:17:28 (depending on whether you want it to apply to everyone, or _someone_) 23:17:40 https://github.com/omniosorg/omnios-extra/blob/master/build/fping/local.mog#L15 23:17:40 https://github.com/omniosorg/omnios-extra/blob/master/build/fping/files/exec_attr 23:17:47 Correct. A binary that some sysadmin has "blessed" as being OK to have some additional privilege. (Conceptually like setuid but much less dangerous:) 23:17:59 yes, that's exactly forced privileged 23:18:03 see hadfl's link :) 23:18:24 Thanks. 23:25:05 would be nice to bypass the usage of mlock(3) as it does for other platforms so we don't need to raise the priv bar. we had to cover a lot of areas at the time so got away with ppriv hack to "make things just work" (TM). :D 23:55:06 Do other platforms have vforkx()? 23:55:43 That would be a little better, with the two flags: FORK_NOSIGCHLD + FORK_WAITPID 23:56:10 nevermind, wrong room.