Re: Problem with the privileges of the KEXT package...
Re: Problem with the privileges of the KEXT package...
- Subject: Re: Problem with the privileges of the KEXT package...
- From: Stéphane Sudre <email@hidden>
- Date: Wed, 29 May 2002 12:55:46 +0200
On Wednesday, May 29, 2002, at 09:17 AM, Kevin Van Vechten wrote:
Moreover than making the KEXT inaccessible to the group, it probably
should not be in /Library/, since that is (and should be) group
writable, limiting the effectiveness of any permissions to the KEXT. A
purist such as myself would contend that KEXTs belong in
/System/Library/Extensions, owned by root:wheel.
On Tuesday, May 28, 2002, at 08:37 PM, Dean Reece wrote:
Right; the "standard" permissions we recommend are 644 for files and
755 for dirs. The owner/group should be root/wheel.
Minimally, your kext (all files & dirs) must be owned by root and may
not be writable by any user other than root. Obviously, to be read by
the kext loading system they need to be readable by root, but should
also be readable by non-root users in order for Finder and
AppleSystemProfiler to be able to present them in the GUI.
Thanks for all the answers, I tested with just removing the write
permission to the files and folders and it's now working. Cool.
Yet I must confess I have some problems with this scheme.
1) I don't like putting 3rd party kext (mine or others) in
/System/Library/Extensions:
* Since the Apple Installer which I'm using does not provide any
Uninstall feature, the End User can't remove stuff in /System since he
can't guess where it is and sometimes he can't even guess the name of
the file or determine whether this is an Apple Extension or a 3rd party
Extension.
* If you install 3rd party files in /System/Library/, the user will have
reasons to dig in /System/Library/Extension. First thing he will do is
to remove the Graphic Drivers he does not need. Even though these
drivers are not loaded at boot-time. He will also remove the iPod
driver, the Apache Startup Items, etc... This will lead to a corrupted
System Folder which may lead to incorrect Mac OS X updates.
* If one user can change stuff in /Library/ he can change stuff in
/System/Library too. Since Admin users in OS X are in staff, admin,
wheel, they can become root and trash /System/Library. So /Library is
not more protected than /Library to these users. The protection to
common users is the same in /System and /Library (other: r-x for folders
and r-- for files).
* I don't see a great interest in putting StartupItems in /Library and
the associated kexts in /System/Library/Extensions. To remove the whole
package you would need to remove components at 2 locations when you can
only remove components at one location.
* I don't see the interest of being able to put StartupItems in /Library
if you can't put their associated kext inside them. I thought the Mac OS
X experience was to group stuff and not putting them everywhere when
possible.
2) I do agree with the fact that owner/group must be root/wheel for
items inside /System but I do not agree that it should be the case when
they are in /Library.
* Since the owner/group of /Library is root/admin, this would be
incoherent.
* The kextload tool does not care at all whether the files are
root/wheel or root/admin. It just works with root/admin.
3) I don't see the interest to deny group write permissions to a kext
associated to a StartupItem.
* Denying write permissions prevent the file to be deleted from the
Finder. See point above about the Apple Installer.
* Denying write group permissions protects almost nothing:
- Prevent the deletion of the kext: not really (see above)
- Prevent files with inappropriate permissions to be launched at boot
time: Startup Items can be in /Library/ and their associated scripts or
binary can be rwxrwxr-x root/admin, and are launched at boot time.
- If it's there to prevent the End user from deleting the file, write
group permissions with root/admin is fine too.
With the current permissions giving write permission to the admin group,
what I'm experiencing is this:
- End User can't delete the items
- End User can't delete the /Library folder
- End User can't change the items
- Admin User can delete /Library
- Admin User can delete /System
- Admin User can delete the items (included from the Finder)
- Admin User can change the items
I'm trying to imagine a case where giving write permissions to the admin
group can lead to a security issue but since this is already the case
with StartupItems...
Any opinion?
Side note: is there any official Apple/Darwin document which lists the
recommended file permissions for the various standard locations?
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.