lkml.org 
[lkml]   [2004]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patches in this message
/
Date
From
Subject[PATCH] Re: 2.6.x BSD Process Accounting w/High UID
On Thu, 4 Mar 2004, Arthur Corliss wrote:

> Second: I don't want new userspace tools, either, but I do want the ones
> I've got to work, which is what they don't do when it reports the lower bits
> of the uid field on high uids. In other words, the tools are *already*
> broken. I realise that I'm probably a corner case in that most admins will
> never assign high uids, but that really doesn't make me feel better about
> broken tools. ;-)

But the current tools are only broken for the few people using high UIDs
(and generally on 64 bit archs, but that's a different story).

We shouldn't require people to recompile their userspace tools in the
middle of a stable kernel series. (OK, 2.6 has just started, but we don't
want to offend people upgrading from 2.4, either.)

How about the patch below? It requires a change to userspace tools if you
want to use high uids, but it dosn't break binary compatibility. It even
allows userspace to check whether high UIDs are supported, and allows
future incompatible format changes to be detected.


> > btw: if you actually push an incompatible change, could we do something
> > about large times as well?
>
> If the numbers we're logging are meaningless, then hell, yes, let's fix them
> all!

Well, they are not totally meaningless since we clip at the maximum
representable value instead of wrapping around.

Still, I'd prefer to do something about this as well. Will send out a
patch to deal with both things in a few minutes. (Note to Andrew/Linus:
please don't apply the patch below before considering the other patch :-)


Tim


diff -urpP --exclude-from dontdiff linux-2.6.4-rc1/include/linux/acct.h linux-2.6.4-rc1-acct/include/linux/acct.h
--- linux-2.6.4-rc1/include/linux/acct.h 2004-02-04 04:43:17.000000000 +0100
+++ linux-2.6.4-rc1-acct/include/linux/acct.h 2004-03-07 18:03:48.000000000 +0100
@@ -33,6 +33,7 @@ typedef __u16 comp_t;
*/

#define ACCT_COMM 16
+#define ACCT_VERSION 1

struct acct
{
@@ -56,7 +57,10 @@ struct acct
comp_t ac_swaps; /* Accounting Number of Swaps */
__u32 ac_exitcode; /* Accounting Exitcode */
char ac_comm[ACCT_COMM + 1]; /* Accounting Command Name */
- char ac_pad[10]; /* Accounting Padding Bytes */
+ __u16 ac_uid_hi; /* Accounting Real User ID */
+ __u16 ac_gid_hi; /* Accounting Real Group ID */
+ char ac_pad[5]; /* Accounting Padding Bytes */
+ char ac_version; /* Always set to ACCT_VERSION */
};

/*
--- linux-2.6.4-rc1/kernel/acct.c 2004-02-04 04:43:56.000000000 +0100
+++ linux-2.6.4-rc1-acct/kernel/acct.c 2004-03-07 18:03:39.000000000 +0100
@@ -270,11 +270,19 @@ void acct_auto_close(struct super_block
#define MANTSIZE 13 /* 13 bit mantissa. */
#define EXPSIZE 3 /* Base 8 (3 bit) exponent. */
#define MAXFRACT ((1 << MANTSIZE) - 1) /* Maximum fractional value. */
+#define MAXVAL ((unsigned long long) MAXFRACT << (EXPSIZE*((1<<EXPSIZE)-1)))
+ /* Maximum encodable value. */

static comp_t encode_comp_t(unsigned long value)
{
int exp, rnd;

+ /*
+ * On 64 bit platforms, value may be too large to fit into a comp_t.
+ */
+ if (value > MAXVAL)
+ return (comp_t) -1;
+
exp = rnd = 0;
while (value > MAXFRACT) {
rnd = value & (1 << (EXPSIZE - 1)); /* Round up? */
@@ -342,7 +350,9 @@ static void do_acct_process(long exitcod
ac.ac_stime = encode_comp_t(current->stime);
/* we really need to bite the bullet and change layout */
ac.ac_uid = current->uid;
+ ac.ac_uid_hi = current->uid >> 16;
ac.ac_gid = current->gid;
+ ac.ac_gid_hi = current->gid >> 16;
ac.ac_tty = current->tty ? old_encode_dev(tty_devnum(current->tty)) : 0;

ac.ac_flag = 0;
@@ -374,6 +384,7 @@ static void do_acct_process(long exitcod
ac.ac_majflt = encode_comp_t(current->maj_flt);
ac.ac_swaps = encode_comp_t(current->nswap);
ac.ac_exitcode = exitcode;
+ ac.ac_version = ACCT_VERSION;

/*
* Kernel segment override to datasegment and write it
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.080 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site