Mark Shellenbaum wrote:
> Mark Shellenbaum wrote:
>> Gary Winiger wrote:
>>>>> How will this affect audit of chown(2), acl(2)? In particular
>>>>> when
>>>>> the audit trail file is processed on another system, or after a
>>>>> reboot? Will ephermeral uid's be stored in the audit trail file?
>>>>> How will praudit(1M), auditreduce(1M) be changed by this project?
>>>>>
>>>>> Gary..
>>>> This change doesn't change any syscalls. All it does is allow a
>>>> user to specify SIDs and then uses the idmap(1M) API to convert
>>>> those to ephemeral IDs.
>>>
>>> Right and doesn't it store ephemeral IDs in the audit trail file?
>>> IIRC, ephemeral IDs were never supposed to survive reboots or
>>> be transfered to other systems. Audit trail files can be moved
>>> from the machine on which they were created; they can be processed
>>> after the system has been rebooted. How are ephemeral IDs
>>> processed in
>>> those environments? That is, "How will praudit(1M), auditreduce(1M)
>>> be changed by this project?" praudit translates user/group IDs to
>>> user/group names. auditreduce selects files based on fileowner
>>> and or filegroup.
>>>
>>> Gary..
>>
>> It probably does store ephemeral IDs in audit trails today. That
>> sounds like a bug that has been then since
>>
>> PSARC 2007/064 Unified POSIX and Windows Credentials for Solaris
>>
>> added support for ephemeral IDs.
>>
>> -Mark
>>
>
> I will run a test and see what currently gets audited with ephemeral IDs.
>
> -Mark
>
>
With stock Nevada bits I have a system with a few ephemeral IDs that are
available from some previously accessed files that were created by the
CIFS server.
# idmap dump
usid:S-1-5-21-940912991-1138591764-871648236-1119 ==
uid:2147483649
usid:S-1-5-21-940912991-1138591764-871648236-1138 ==
uid:2147483650
gsid:S-1-5-21-940912991-1138591764-871648236-1127 ==
gid:2147483650
gsid:S-1-5-21-940912991-1138591764-871648236-513 ==
gid:2147483651
Then I created a special testuser which has priv_file_chown and
priv_file_chown_self and then I used this command to change the
ownership of a file to an ephemeral id
$ chown 2147483650 file.1
This results in the following audit record
header,196,2,chown(2),sp,hidenseek,2008-05-28 07:55:02.896 -06:00
argument,2,0x80000002,new file uid
argument,3,0xffffffff,new file gid
path,/sandbox/test1/file.1
Now within ZFS the file ownership is changed to the following. This
output comes from zdb. This will show what the real FUID inside ZFS is.
# zdb -vvv sandbox/test1
...
Object lvl iblk dblk lsize asize type
5 1 16K 512 512 0 ZFS plain file
264 bonus ZFS znode
path /file.1
uid 100000472 [S-1-5-21-940912991-1138591764-871648236-1138]
gid 1
atime Wed May 28 07:54:43 2008
mtime Wed May 28 07:54:43 2008
ctime Wed May 28 07:55:02 2008
crtime Wed May 28 07:54:43 2008
gen 23424
mode 100644
size 0
parent 3
links 1
xattr 0
rdev 0x0000000000000000
Indirect blocks:
If ephemeral Ids are not suppose to be in the audit trail then I would
suggest you open a bug. Changing the way ephemeral IDs are audited is
not part of this case.
-Mark
