svn commit: r232181 - in head/sys: kern sys

John Baldwin jhb at freebsd.org
Tue Feb 28 15:18:27 UTC 2012


On Tuesday, February 28, 2012 1:34:25 am Julian Elischer wrote:
> On 2/27/12 1:29 AM, Konstantin Belousov wrote:
> > On Mon, Feb 27, 2012 at 10:49:59AM +0200, Mikolaj Golub wrote:
> >> On Mon, 27 Feb 2012 09:28:11 +0100 Pawel Jakub Dawidek wrote:
> >>
> >>   PJD>  On Sun, Feb 26, 2012 at 02:25:48PM +0000, Mikolaj Golub wrote:
> >>   >>  Author: trociny
> >>   >>  Date: Sun Feb 26 14:25:48 2012
> >>   >>  New Revision: 232181
> >>   >>  URL: http://svn.freebsd.org/changeset/base/232181
> >>   >>
> >>   >>  Log:
> >>   >>    Add sysctl to retrieve or set umask of another process.
> >>
> >>   PJD>  "set umask of another process"? This seems... weird. What's the purpose
> >>   PJD>  of this change?
> >>
> >> When we were discussing this with Kostik and Robert, and I asked if it could
> >> be useful to have the sysctl rw, Kostik described a real situation when he had
> >> had to change umask of another process: umask had not been set properly on an
> >> aplication start but it could not be restarted until the end of the day.
> >> Kostik was able to fix it using gdb but having an easier way looked useful.
> > kgdb, not gdb.
> >
> > It is indeed possible to write a ptrace-based utility that inject a code
> > payload that would change umask. Since this is very risky but indeed possible,
> > having the straighforward kernel facility is justified.
> Why not have a sysctl to change a process'  uid, cwd, memory limits, 
> etc. etc.

uid and cwd would be rediculous to change.  However, we recently added sysctls
to allow a sysadmin to read and write the limits of other processes (and that
is a very useful feature indeed since it is not unusual for a long-running
process to require more resources than it was initially allocated, as is the
ability to easily query the limits that a given process is subject to).

> I don't think this belongs in the kernel by default. It's not exactl a 
> call for backout but It's teh next thing short of that. a call for "do 
> you REALLY think we need this particular specific case catered for?"

That said, the umask bit does strike me as a bit more odd than the limits
case.  I would have more need of a tool to let me adjust the listen queue
length of a socket than to adjust umask (I've had to do that multiple times
via kgdb).

-- 
John Baldwin


More information about the svn-src-head mailing list