[illumos-gate] 16626 sockfs: 'save_so_backlog' may be used uninitialized -- Toomas Soome <tsoome⊙mc>

Can anyone remind me how /etc/security/exec_attr gets updated from the exec_attr.d/* files?

are you sure it does? I would guess they are just merged

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

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."

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?

if it's privileges (and not authorizations), ppriv(1) should do that

(and of course you can specify all of that in an smf manifest if it's meant to be a service)

but if you want to 'allow non-priv user to run this', then yeah, i think pfexec would do it as well

Hm. Ideally want it to be just grated to this program, for whoever runs it.

then yeah, i think exec_attr + pfexec would do it

or i think if you use pf{bash,ksh,...} that might also do it automatically for you (but not 100% sure on that one)

Wish we didn't need the pfexec. Not sure how to get that when I run it under gdb.

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

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.

pfexec essentially is a tool to avoid to update your app code

so, it means, you can start pfbash, and use gdb from it without the need to use pfexec with your program you are debugging.

pf* works via pfexecd and magic

in theory, ln -s $(which gdb) pfgdb will do what you think it will

that too, yes:D

Really? pfgdb? I'll try :)

Hm. ppriv says just plain old basic

It would be cool if there were a way to mark an executable such that exec would do pfexec work.

Something like "wants pfexec"

that's what pfexecd does

suid?

but I'm not sure what it's doing to you instead

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

as I have sys_mount added to my user, ppriv run with gdb pid (run as pfgdb), does list sys_mount

so, if the command has privileges set via exec_attr, you would need the profile configured with your user.

I'm pretty sure I typoed in the command, and the link should have gone to pfexec not the normal gdb

and I think toomas has read what I meant to type and tried that :)

so a hardlink pfgdb -> pfexec

yes, you link with pfexec (similar as with isaexec)

cf. pfbash's inode and pfexec's

sorry my brain is a black hole

I guess I have instructed too many of the solaris sysadmin trainings:D some things do come without thinking;)

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

Thanks.

(packages that deliver files in there also must deliver an actuator to restart that FMRI etc)

gwr: Also, if you want to do something automatic with privileges, look at, e.g., "rsh" and the "Forced Privilege" profile

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

it is inscrutable, but very cute

compared to modifying every piece of software

I wonder if anything cares about the "sticky" bit on files anymore? Maybe that could trigger pfexec actions on exec?

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

that's exactly what forced priv that jclulow mentioned does, or what a pf* link etc would do

we ship a few binaries in omnios where we do exactly that. set suid then limit what they can do

(depending on whether you want it to apply to everyone, or _someone_)

Correct. A binary that some sysadmin has "blessed" as being OK to have some additional privilege. (Conceptually like setuid but much less dangerous:)

yes, that's exactly forced privileged

see hadfl's link :)

Thanks.

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

Do other platforms have vforkx()?

That would be a little better, with the two flags: FORK_NOSIGCHLD + FORK_WAITPID

nevermind, wrong room.