Yes, world readable/writable files can still be accessed by dropping the new
privileges. One reason are library calls that need to read some public files
(like things in /etc). The need to manipulate or remove world writable files is
harder to justify, on the other hand, world writable files are hard to find.
One may define two additional basic privileges (say
PRIV_FILE_ALLOW_{WRITE|READ}) that would be checked first, but so, we have two
further privileges 8-)
-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED] im Auftrag von [EMAIL PROTECTED]
Gesendet: Do 22.06.2006 11:55
An: Nicolas Williams
Cc: Nicolai Johannes; [EMAIL PROTECTED]; zfs-discuss@opensolaris.org; Mark
Shellenbaum
Betreff: Re: AW: AW: [zfs-discuss] Proposal for new basic privileges related
with filesystem access checks
>On Thu, Jun 22, 2006 at 01:01:38AM +0200, [EMAIL PROTECTED] wrote:
>> I'm not sure if I like the name, then; nor the emphasis on the
>> euid/egid (as those terms are not commonly used in the kernel;
>> there's a reason why the effective uid was cr->cr_uid and not cr_euid.
>>
>> In other words, what your are doing is creating a "nobody" user with
>> an ordinary user id.
>
>Yes. It's kind of enticing.
I'm not entirely clear as to the problem which it solves; I think
I'd much rather have a user which cannot modify anything.
As I understand the proposal, you can still read/modify world
accessible files.
>As I interpret the proposal file creation in /tmp would succeed, but
>opening existing files owned by the process' actual euid cannot be
>opened if thes basic privs are dropped.
Right; but often programs work by reopening such files; that will now
fail.
>How would dropping this basic priv work with NFS though?
Not until we make privileges visible over NFS which is a tough nut
to crack.
Casper
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
