2012-08-21 2:18, Gordon Ross пишет:
On Fri, Aug 17, 2012 at 5:44 AM, Frank Lahm <frankl...@gmail.com> wrote:
2012/8/17 James Relph <ja...@themacplace.co.uk>:
[...]
Thanks very much for that confirmation, really doesn't seem obvious in a lot of
the documentation! I don't have a system handy to test today (will do over the
weekend) but I'll try and get a better idea of how that works over the weekend
(in particular after a reboot, what UID/GID will a file/folder show (ie. with
ls) until the same user logs in again and the new ephemeral mapping is
created?).
ephemeral ids break setuid/seteuid because they are not static on a
_running_ system. They may change anytime. Thus any POSIX compliant
application relying on these functions for privileges can not use
them.
Really? Where is your evidence? I don't think I've ever seen one
change except after a reboot.
As a wild guess (no evidence and no code reading):
* Can this happen upon restart of idmap daemon (i.e. state stored
only in RAM)?
* Upon an ungraceful crash (as in kill -9 due to memory leaks,
which I saw piling up over 1-2 months, with the daemon consuming
about 3Gb of memory and then a CPU core sometimes, on SXCE 117)?
From what I've seen, it uses an embedded SQL database which may
store the mappings and survive even reboots, but I have no idea
how really sturdy and reliable that mechanism is, especially in
modern revisions.
//Jim
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
