headers
Russ Weeks | 2 Aug 2007 20:37

pkgadd privileges

Hi, All.

I want to package my J2EE-based application as a Solaris package so that 
it can be installed via pkgadd.

Before the application can run properly the configuration files must be 
parameterized with the correct database connection info.  The package's 
postinstall script seems like the natural place to do this configuration.

I see that pkgadd must be run with root credentials - this makes sense. 
  But the root user may not know enough about my application to properly 
configure it.  The application administrator, who does, may not have 
root-like access to the system.

I must not be the first person to run into this catch-22... are there 
any recommended best practices here?

Thanks,

Russ
Permalink | Reply | 4 comments |
headers
John Martinez | 3 Aug 2007 01:41
Picon

pkgadd privileges


You can accomplish this with sudo or RBAC. Take your pick.

RBAC is cleaner in Solaris, but sudo is more "standard" in that more  
UNIX-like systems are set up with sudo (Linux, Mac OS X, etc.). And  
RBAC will take a little more reading to get going.

In my environment at work, I've employed a combination of both  
approaches.

-john

On Aug 2, 2007, at 11:37 AM, Russ Weeks wrote:

> Hi, All.
>
> I want to package my J2EE-based application as a Solaris package so  
> that
> it can be installed via pkgadd.
>
> Before the application can run properly the configuration files  
> must be
> parameterized with the correct database connection info.  The  
> package's
> postinstall script seems like the natural place to do this  
> configuration.
>
> I see that pkgadd must be run with root credentials - this makes  
> sense.
>   But the root user may not know enough about my application to
(Continue reading)

Permalink | Reply | 2 comments |
headers
Russ Weeks | 3 Aug 2007 02:01

pkgadd privileges

Thanks, John.

In this case, do you give RBAC/sudo access to pkgadd in its entirety, or 
do you give RBAC/sudo access to a set of specific commands, ie. 'pkgadd 
SomePackage'?  The first case seems to liberal, the second case too strict.

There was some discussion about this on security-discuss around 7/16/06, 
"ROLE and Profile Improvements".  I don't think it really went anywhere. 
Is that a more appropriate forum for this question?

Thanks,

Russ

John Martinez wrote:
> 
> You can accomplish this with sudo or RBAC. Take your pick.
> 
> RBAC is cleaner in Solaris, but sudo is more "standard" in that more 
> UNIX-like systems are set up with sudo (Linux, Mac OS X, etc.). And RBAC 
> will take a little more reading to get going.
> 
> In my environment at work, I've employed a combination of both approaches.
> 
> -john
> 
> On Aug 2, 2007, at 11:37 AM, Russ Weeks wrote:
> 
>> Hi, All.
>>
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Martinez | 3 Aug 2007 02:15
Picon

pkgadd privileges


On Aug 2, 2007, at 5:01 PM, Russ Weeks wrote:

> Thanks, John.
>
> In this case, do you give RBAC/sudo access to pkgadd in its  
> entirety, or do you give RBAC/sudo access to a set of specific  
> commands, ie. 'pkgadd SomePackage'?  The first case seems to  
> liberal, the second case too strict.

No, I give access to a specific command, as in 'pkgadd', arguments  
not included. I believe in sudo you can explicitly spell out command  
arguments. I'm not sure in RBAC. I *think so*, but I'm not sure. I  
agree that one is too liberal and the other too strict. 'Tis the  
choice, I guess. I think I know where you're going with this, though.  
You don't want that user to install any package they want, just a  
specific set of packages.

As an option, you can always wrap pkgadd around your own shell/perl  
scripts, limiting what can be installed. In an example I did at work,  
I needed to give our directory team access to automatically create  
home directories on the file servers. I used RBAC as a specific UID/ 
GID combo, allowed access to only one command, a perl script that  
does the home directory creation the way I wanted them to, instead of  
allowing that user the privilege to run 'mkdir' on its own as EUID=0.

> There was some discussion about this on security-discuss around  
> 7/16/06, "ROLE and Profile Improvements".  I don't think it really  
> went anywhere. Is that a more appropriate forum for this question?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Gerdts | 3 Aug 2007 04:33
Picon

pkgadd privileges

On 8/2/07, Russ Weeks <rweeks at redback.com> wrote:
> Hi, All.
>
> I want to package my J2EE-based application as a Solaris package so that
> it can be installed via pkgadd.
>
> Before the application can run properly the configuration files must be
> parameterized with the correct database connection info.  The package's
> postinstall script seems like the natural place to do this configuration.

But the request script is the only place that it should ask the
questions.  Those responses end up in the commonly world-readable file
/var/sadm/pkg/≤pkg>/pkginfo (or similar) file.  As such, if the
information is deemed sensitive, it should not be populated this way.

> I see that pkgadd must be run with root credentials - this makes sense.
>   But the root user may not know enough about my application to properly
> configure it.  The application administrator, who does, may not have
> root-like access to the system.

Instead of making the file only modifiable by root, make it modifiable
by an application administration account or group.  You could prompt
for the account name in the request script, create it as required in
the postinstall script, and set permissions (then call installf to be
sure that /var/sadm/install/contents is fixed) in the postinstall
script.

> I must not be the first person to run into this catch-22... are there
> any recommended best practices here?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raymond LI - Sun Microsystems - Beijing China | 7 Aug 2007 08:03
Picon

[networking-discuss] [brussels-dev] [driver-discuss] pausel bits setting within Solaris

Guys, would we come up with some conclusion on this?

1. What UI to provide, meaningful strings or numerical on/off?
I think all of us agree to have a more straightfoward UI for customer to 
config.
And we have below two proposed UI so far.
(1) flowcontrol = {send, accept, disable, both}
(2) accept_pause = {0, 1}, send_pause = {0, 1}
Seems (1) is more concise.

2. Will we still keep our ieee802.3(5) manpage definations as underlying 
implementation?
I think before IEEE has new idea on them, we just keep them as what they 
are today.
But we don't provide interfaces to directly tune them anymore. User 
still could check the
values as read-only for debug/diag purpose.

Looking forward to your suggestions.

Thanks,

Raymond

Raymond LI - Sun Microsystems - Beijing China wrote:
> Guys:
>
> Could we conclude we could implements pause control like below?
> We want to leave ieee802.3 beneath the scene while providing user with a 
> UI which makes more sense.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rainer Heilke | 7 Aug 2007 15:39
Favicon

[networking-discuss] [brussels-dev] [driver-discuss] pausel bits setting within Solaris

Sorry, I haven't really been part of this discussion. Here are my 
votes/opinions.

Raymond LI - Sun Microsystems - Beijing China wrote:

>Guys, would we come up with some conclusion on this?
>
>1. What UI to provide, meaningful strings or numerical on/off?
>  
>
I vote for meaningful strings.

>I think all of us agree to have a more straightfoward UI for customer to 
>config.
>And we have below two proposed UI so far.
>(1) flowcontrol = {send, accept, disable, both}
>(2) accept_pause = {0, 1}, send_pause = {0, 1}
>Seems (1) is more concise.
>  
>
Flow control seems clearer.

>2. Will we still keep our ieee802.3(5) manpage definations as underlying 
>implementation?
>I think before IEEE has new idea on them, we just keep them as what they 
>are today.
>  
>
Not sure on this one.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aaron | 7 Aug 2007 19:12
Picon

/var/sadm/pkg missing??

I have a test system here to which, unfortunately, many people have root access.  One of our software
installs is failing because the showrev -p command fails.

I ran truss on the showrev -p command and it looks as though it is trying to open the directory /var/sadm/pkg,
which is completely missing.

Long story short: is there any way to re-create the /var/sadm/pkg directory and all of its installed
package information?

Any suggestions would be greatly appreciated...

-Aaron

 
This message posted from opensolaris.org
Permalink | Reply | 0 comments |
headers
Joost Mulders | 7 Aug 2007 21:51
Picon

[driver-discuss] [networking-discuss] [brussels-dev] pausel bits setting within Solaris

My votes:
> 1. What UI to provide, meaningful strings or numerical on/off?
Strings.

> I think all of us agree to have a more straightfoward UI for  
> customer to
> config.
> And we have below two proposed UI so far.
> (1) flowcontrol = {send, accept, disable, both}
flowcontrol

> 2. Will we still keep our ieee802.3(5) manpage definations as  
> underlying
> implementation?
Yes, I think so. Any "well defined" set is OK, this can be be ieee802 
(5).

> I think before IEEE has new idea on them, we just keep them as what  
> they
> are today.
> But we don't provide interfaces to directly tune them anymore. User
> still could check the
> values as read-only for debug/diag purpose.
>
> Looking forward to your suggestions.
>
> Thanks,
>
> Raymond
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Raymond LI - Sun Microsystems - Beijing China | 8 Aug 2007 05:49
Picon

[networking-discuss] [brussels-dev] [driver-discuss] pausel bits setting within Solaris

Rainer Heilke wrote:
> Sorry, I haven't really been part of this discussion. Here are my 
> votes/opinions.
>
> Raymond LI - Sun Microsystems - Beijing China wrote:
>
>> Guys, would we come up with some conclusion on this?
>>
>> 1. What UI to provide, meaningful strings or numerical on/off?
>>  
>>
> I vote for meaningful strings.
>
>> I think all of us agree to have a more straightfoward UI for customer 
>> to config.
>> And we have below two proposed UI so far.
>> (1) flowcontrol = {send, accept, disable, both}
>> (2) accept_pause = {0, 1}, send_pause = {0, 1}
>> Seems (1) is more concise.
>>  
>>
> Flow control seems clearer.
OK, let's do that with flowcontrol and string values.
>
>> 2. Will we still keep our ieee802.3(5) manpage definations as 
>> underlying implementation?
>> I think before IEEE has new idea on them, we just keep them as what 
>> they are today.
>>  
>>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane