Vassilii:
> I am trying to understand what's the cleanest coding that would allow
> 1) user code to just use uid/gid for interfacing the driver control
> structures
> 2) driver code to read/write the corresponding structure fields with minimum
> awareness of the actual difference between kernel a
this is made explicit:
#ifdef __KERNEL__
typedef __kernel_uid32_tuid_t;
typedef __kernel_gid32_tgid_t;
...
...
Thanks,
Chris Wing
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
nstead of nobody because its programmer used pthreads and assumed
that setuid() would affect all threads.
I pointed this out to the author and Red Hat, and it was fixed in
pidentd 3.0.11 and Red Hat 6.2.
-Chris Wing
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe
Andreas:
My changes for process accounting were not accepted along with the rest of
the 32-bit UID patches. The current state of things as I understand it is
that SGI is working on some "enhanced" accounting support for Linux, which
may end up replacing the current process accounting. (stuff like
a pid overflow, to programs using the older structures.
-Chris Wing
[EMAIL PROTECTED]
> (ii) There is also a rather obscure place in SYSV IPC where a 16-bit pid_t
> is used for the fields msg_lspid and msg_lrpid of the (obsolete)
> struct msqid_ds and the fields shm_cpid and shm_lpid of
at tar files do
not store textual usernames.
-Chris Wing
[EMAIL PROTECTED]
> Not true. All the kernels I download from a certain local mirror are owned
> by the local user 'tarabas' since the uid happens to be the same with
> those on the mirror site. So numeric uids.
-
To un
6 matches
Mail list logo
