Roland Mainz wrote:
> John Sonnenschein wrote:
>   
>> Mike Gerdts wrote:
>>     
>>> On Mon, Sep 29, 2008 at 4:07 PM, Gary Winiger <gww at eng.sun.com> wrote:
>>>
>>>       
>>>>> suid binary in /usr/bin:
>>>>>
>>>>> - allows users to change their own shell
>>>>> - via RBAC allows users with the solaris.admin.usermgr.write privilege
>>>>> to change anyone's shell
>>>>>
>>>>>           
>>>>        Kind of like chfn and chsh.  Which IIRC were just links to passwd.
>>>>        Why do we need an authorization to change our own shell?
>>>>         
>>> Because...
>>>
>>> - Those with restricted shells should not be able to change their own 
>>> shells.
>>>
>>>       
>> Understood. Is there a way to check for this easily? ( or failing that
>> have it denied for rXsh users ? )
>>     
>
> Erm... "restricted shells" should never have /usr/bin/ or /usr/sbin/ in
> their PATH and therefore this is not an issue (AFAIK search
> shell-discuss@, somewhere is a good description about restricted shell
> mode vs /usr/bin/).
>
>   
>>> - Administrators should be able to deny this ability because of local
>>> policy (e.g. the admin maintains Bourne shell compatible environment
>>> files but doesn't and won't do the same for csh compatible shells).
>>>       
>> putting it in a separate package sufficient, or would an /etc/chsh.deny
>> file be the preferred method?
>>     
>
> AFAIK _both_ ways are needed (and you need both /etc/chsh.allow and
> /etc/chsh.deny (and I suggest |libast::fnmatch()| since it allows to
> select various pattern matching systems (e.g. regex-, regexp-, fgrep-,
> perl- etc. pattern) besides shell pattern to be used in these files)).
>   

linking to libast seems like a lot of bloat for such a simple util, so 
it's not really worth it. I should hope that the system admin, should 
they want to restrict the use of chsh, could just not install the package

>>> As for chfn(1), I've worked in multiple places where the gecos field
>>> is used to store the full name and a special key (e.g. employee badge
>>> number) that is assumed to be reliable data to other systems.  It can
>>> be critical that this does not become user modifiable to maintain
>>> integrity of some identity management schemes.
>>>       
>> I agree, not a fan of chfn
>>     
>
> Why ? At least the name and functionality seems to be quite common..

Because it's not the problem I'm trying to solve. I'm trying to solve 
the problem of not being able to change my shell on machines I don't 
own, not munge all the information about my user. That can come some 
other time when I care about that

Reply via email to