The macosxhints Forums - Test FinkCommander...

The macosxhints Forums (http://hintsforums.macworld.com/index.php)

- OS X Developer (http://hintsforums.macworld.com/forumdisplay.php?f=27)

- - Test FinkCommander... (http://hintsforums.macworld.com/showthread.php?t=2749)

Test FinkCommander...

Anybody out there brave enough to test FinkCommander ?

<<FinkCommander is a graphical user interface for the Fink software packaging system for Mac OS X. It provides an intuitive front-end to the Fink command-line tools for downloading and installing Unix software.

FinkCommander has not been widely tested and may do damage to your system. It also raises some security concerns, which are documented in the README.>>

http://finkcommander.sourceforge.net/

Cheers...

It looks like a good idea. I'll prolly try it after the password thing is taken care of.

hmm, it makes you wonder what other apps have we been tinkering with that don't implement the security framework. i wonder if there is a command to examine an executable and determine "does she or doesn't she?"

Craig,

Good luck, your feedback appreciated.

MervTormel,

Other than looking at the source code, I don't know of any command. (I wish I knew...then we could check all the new app we try everyday).

By the way, I felt inspired so I offered myself to do the spanish localization.

Cheers...

$ strings /Applications/Utilities/NetInfo\ Manager.app/Contents/MacOS/NetInfo\ Manager | grep auth
Deauthenticate
Authenticate...
AuthenticationChanged
You must re-authenticate to make additional changes.
authMenu
deauthenticateUser:
authenticateUser:
isAuthenticated
isAuthenticatedAsAdministrator
deAuthenticateUser:
authenticateAsUserName:password:
deauthenticate
authenticate
You have deauthenticated with unsaved changes. Those changes have been lost.
updateAuthentication:
neverDeauthenticated
authenticationButton
deauthenticated
willAuthenticate
authenticationSuccessfulForDomain:userName:password:
hasAuthenticationForDirectory:
allowNonAdminAuthentication:
isAuthenticatedAsUserName:
isAuthenticatedAsRoot
Authentication failed!
NIAuthenticationPanel
authenticated
authenticateFor:
authenticatedFor:
authHost:andGetPassword:
authenticateWithPassword:
authenticationPanel
Can't authenticate new user and password

$ strings xdowns/finkcommander-0.2.1a/FinkCommander.app/Contents/MacOS/FinkCommander | grep auth

$

$ strings /Applications/Utilities/Installer.app/Contents/MacOS/Installer | grep auth
IsAuthenticated
IFInstallerAuthenticated
isAuthenticated
setIsAuthenticated:

$ strings /Applications/Utilities/Keychain\ Access.app/Contents/MacOS/Keychain\ Access | grep auth

$

$ strings /Applications/Utilities/ProcessViewer.app/Contents/MacOS/ProcessViewer | grep auth

$

MervTormel,

Interesting work, will check more of it.

Cheers...

i'm looking for something in the /developer tree to explode frameworks of an executable. if we could find that, then discover the footprint of the security framework, then we could write a little script to profile apps.

MervTormel,

We can learn somethings from this article by Brian R. Hill, the developer of Brickhouse: (Sorry a little long)

<<One of the many changes that greeted developers when Mac OS X 1.0 was released was that the 'root' user was no longer allowed to login by default. This meant that many time-honored ways of launching command line tools with administrative privileges, such as using the 'su' tool, no longer worked.

Instead, Apple has provided a new framework, Security, to handle user authentication and launching administrative command line tools with root access, among other things. This new framework also provides a foundation for more sophisticated authorization architectures with finer granularity, such as role- or time-based access, in the future.

The Security framework introduces a new opaque type, the AuthorizationRef, that represents the current set of authorization privileges held by the user. After initializing an AuthorizationRef, you can use it to discover whether the user has authorization to perform a given task. You can also attempt to increase the authorized privileges, and optionally allow the Security framework to present the user with a panel to enter their password if needed.

To initialize an AuthorizationRef, you use the AuthorizationCreate function.

Code:

#include <Security/Authorization.h>

    #include <Security/AuthorizationTags.h>



    // We'll be hanging onto the authorizationRef

    // and using it throughout the code samples



    AuthorizationRef authorizationRef = NULL;



    // The authorization rights structure holds a reference to an array

    // of AuthorizationItem structures that represent the rights for which

    // you are requesting access.



    AuthorizationRights rights;

    AuthorizationFlags flags;

    

    // We just want the user's current authorization environment,

    // so we aren't asking for any additional rights yet.



    rights.count=0;

    rights.items = NULL;

        

    flags = kAuthorizationFlagDefaults;

    

    err = AuthorizationCreate(&rights, kAuthorizationEmptyEnvironment, 

                              flags, &authorizationRef);

Once you've initialized the AuthorizationRef, you can use the AuthorizationCopyRights function to determine whether the user is currently authorized to do something. To do this, you need to construct an AuthorizationRights structure containing the list of the privileges you require to perform your task.

Code:

AuthorizationItem items[1];

    char sysctlPath[] = "/usr/sbin/sysctl";

    BOOL authorized = NO;

    OSStatus err = 0;



    // There should be one item in the AuthorizationItems array for each

    // right you want to acquire.



    // The data in the value and valueLength is dependent on which right you

    // want to acquire. 

        

    // For the right to execute tools as root, kAuthorizationRightExecute,

    // they should hold a pointer to a C string containing the path to 

    // the tool you want to execute, and the length of the C string path.



    // There needs to be one item for each tool you want to execute.

           

    items[0].name = kAuthorizationRightExecute;

    items[0].value = sysctlPath;

    items[0].valueLength = strlen(sysctlPath);

    items[0].flags = 0;



    rights.count=1;

    rights.items = items;

    

    flags = kAuthorizationFlagExtendRights;

    

    // Since we've specified kAuthorizationFlagExtendRights and

    // haven't specified kAuthorizationFlagInteractionAllowed, if the

    // user isn't currently authorized to execute tools as root,

    // they won't be asked for a password and err will indicate

    // an authorization failure.



    err = AuthorizationCopyRights(authorizationRef,&rights,

                                  kAuthorizationEmptyEnvironment,

                                  flags, NULL);



    authorized = (errAuthorizationSuccess==err);

You can use this to set the state of your ubiquitous lock/unlock button to indicate the user's current authorization status. You should not just cache the result of this and assume that the user will remain authorized. There appears to be a timeout on the AuthorizationRef privileges, and the user may need to re-authorize after an idle period. To be safe, use this technique each time you need to know whether the user is authorized to run your administrative tool.

(continue...in next post)

...from above)

When the user clicks your lock/unlock button, and you'd like the Security framework to present the user with a password panel and check their authorization, you call AuthorizationCopyRights again, this time adding the kAuthorizationFlagInteractionAllowed to the flags.

Code:

AuthorizationRights rights;

    AuthorizationFlags flags;

    AuthorizationItem item[1];

    char sysctlPath[] = "/usr/sbin/sysctl";

    OSStatus err = 0;

    BOOL authorized = NO;



    item[0].name = kAuthorizationRightExecute;

    item[0].value = sysctlPath;

    item[0].valueLength = strlen(sysctlPath);

    item[0].flags = 0;

    

    rights.count=1;

    rights.items = item;

    

    flags = kAuthorizationFlagInteractionAllowed 

               | kAuthorizationFlagExtendRights;



    // Here, since we've specified kAuthorizationFlagExtendRights and

       // have also specified kAuthorizationFlagInteractionAllowed, if the

    // user isn't currently authorized to execute tools as root 

    // (kAuthorizationRightExecute),they will be asked for their password. 



    // The err return value will indicate authorization success or failure.



    err = AuthorizationCopyRights(authorizationRef,&rights,

                                  kAuthorizationEmptyEnvironment,

                                  flags, NULL);

    authorized = (errAuthorizationSuccess==err);

The Security framework will take care of authenticating the user's password, and also notifying the user if the login was incorrect. The only thing that will typically cause this call to return an error is if the user finally gave up and clicked 'Cancel' if they didn't know the password.

To launch the tool with root privileges, you use the AuthorizationExecuteWithPrivileges function. You pass it the AuthorizationRef, the tool path, the arguments for the tool, and an optional FILE* pointer for the tool's standard input and output.

Code:

char* args[3];

    OSStatus err = 0;

    FILE* iopipe;

    

    // The arguments parameter to AuthorizationExecuteWithPrivileges is

    // a NULL terminated array of C string pointers.



    args[0] = "-w";

    args[1]="net.inet.ip.forwarding=1";

    args[2]=NULL;



    err = AuthorizationExecuteWithPrivileges(authorizationRef,

                                             "/usr/sbin/sysctl",

                                             0, args, &iopipe);



    //You can use the standard FILE functions, such as fread, to 

    //read the standard output of the task on iopipe.

If the user clicks your lock/unlock button to deauthenticate themselves, you use the AuthorizationFree function with the kAuthorizationFlagDestroyRights flag.

AuthorizationFree(authorizationRef,kAuthorizationFlagDestroyRights);

It's a good idea to explicitly do this before you quit your program as well, since in the current version of the Security framework, the user will stay authorized for a period of time after they quit your program if you don't destroy the authorization privileges you've acquired.

Along with this article, I've written a small Cocoa application project that uses the SecurityFramework to launch the sysctl tool and set the state of IP packet forwarding. It demonstrates putting a thin Objective C wrapper around these functions to create an easy way to get and set system variables via sysctl and the Security framework.>>

MervTormel,

check : 'man sysctl'

Any ideas?

(Sorry for the long post, but it's a very interesting subject)

Cheers...

Well, security issues aside, it seems to work fine.

I like the sort fields. I'd like it to report a count of installed packages.

Overall. a nice Cocoa front-end to fink. :)

nice pic. no window at your office? i like the juxtaposition of [ rain 46 ° ] and your desktop of outer space. ha. what is that menu weather app? is that weatherPop?

Hehe... my basement is my office; very cavelike. Yes, that's WeatherPop. Desktop pic courtesy the Hubble.

Craig,

Thanks for the picture.

Maybe you send a request about the count of installed packages to sburrios.

Cheers...

not sure if i'm on the right track here, or not, but otool will spit out a lot about the links in an executable...

$ otool -l /Applications/Utilities/Keychain\ Access.app/Contents/MacOS/Keychain\ Access | grep security
name /System/Library/Frameworks/Security.framework/Versions/A/Security (offset 24)
name /System/Library/Frameworks/Security.framework/Versions/A/Security (offset 20)
name /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI (offset 20)
name /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SecurityCore.framework/Versions/A/SecurityCore (offset 20)

$ otool -l xdowns/finkcommander-0.2.1a/FinkCommander.app/Contents/MacOS/FinkCommander | grep security
name /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SecurityCore.framework/Versions/A/SecurityCore (offset 20)
name /System/Library/Frameworks/Security.framework/Versions/A/Security (offset 20)

$ otool -l /Applications/Utilities/NetInfo\ Manager.app/Contents/MacOS/NetInfo\ Manager | grep security
name /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI (offset 20)
name /System/Library/Frameworks/Security.framework/Versions/A/Security (offset 20)
name /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SecurityCore.framework/Versions/A/SecurityCore (offset 20)

--

the only distinction i can see is the SecurityHI.framework in the two apps that we think implement proper authentication. finkcommander's references may only be stubs?

Did a locate for SecurityHI and SecurityCore,

...........

Yes, it looks like SecurityHI deals with Cocoa.framework and Carbon.Framework while SecurityCore deals with the CoreServices.framework.

Cheers...

Hello, all.

I'm the developer of FinkCommander. "Sao" mentioned in an e-mail to me that he had started a thread on FinkCommander here, so I thought I'd take a look.

Craig, I like your suggestion on including the installed package count. There's a version in CVS now that makes it pretty easy to get this information, because it adds "Installed" to the fields you can use in the filter. But I've been thinking that I should add a command to the "Tools" menu that would allow the user to get general fink information, such as the package manager and distribution versions. It would make sense to include the installed package count.

I guess the other alternative would be to put it at the bottom of the window along with the total package count. Something like "1013 packages (150 installed)."

I'll probably be releasing a new version of FinkCommander this weekend, but if you're "brave" enough, you can get the latest changes via anonymous CVS. The instructions are at:

http://sourceforge.net/cvs/?group_id=48896

The primary new feature is the ability to use the Preferences dialog to change the fink.conf file. This makes it very easy to switch to using unstable packages and back again.

Sao, I'm afraid the method that Brian Hill uses to run tasks with root user privileges--launching them with the call to AuthorizationExecuteWithPrivileges--is deprecated. Apple now says you should put all tasks that require root user access in a "small faceless background tool that can be stored inside an application's package." You then use AEWP to make the tool setuid root. This explanation is provided in the README file for the AuthSample sample code at:
http://developer.apple.com/samplecod...AuthSample.htm

I've been trying to figure out how to incorporate the AuthSample approach into FinkCommander. I've read everything I could find on the subject on Apple's web site and on the Apple and OmniGroup mailing lists. I've even been reading the book "Advanced Unix Programming" on Safari (although I really have no business reading anything on Advanced Unix).

I'm beginning to think that using the Security Frameworks in FinkCommander may not be possible, at least for me. I may just have to leave it to users to decide whether they want to risk giving their password directly to the application. Since FinkCommander is open source, what it does with the password is at least transparent.

BTW, This is exactly what FinkCommander does to run commands with root privileges: It runs the command in an NSTask using "sudo -s." If a password prompt appears in the task's standard output, it writes the password to the task's standard input.

sburr,

Thanks to come by. Will get the latest changes from CVS.

The switch unstable/stable through the preferences dialog sounds great.

I'm an optimistic, even after reading about your studies, I still believe that using the Security Frameworks in FinkCommander might be possible. There must be a way...somehow.

Anybody from Apple care to comment ?

Cheers...

Hello,

Thanks for posting the link to the authsample code. I am working on a small app to create users on OS X (practice for a slightly bigger project) and the info is handy. It's an interesting approach that I'll have to get my head around though.

Vonleigh

Hi, sbur! I just this moment sent you an email before I saw your post here. Welcome!

I'll give a shot at the cvs repository as well. I'm liking the error notification feature as opposed to having to monitor stuff in the terminal all the time.