I think we're close to a direction. I definitely agree this should be
an authorisation and not something set in /etc/default/passwd. The only
case where I think this may be bad is with certain customers
(financial, government, etc) may not like this default behaviour. Some
customers don't want user
James Carlson wrote:
> Darren J Moffat writes:
>> There are use cases where it would be acceptable for a user to update
>> the GECOS entry but not change their shell (say they have a restricted
>> shell or profile shell). This means the policy also needs to be at the
>> level of the data item t
James Carlson wrote:
> Glenn Brunette writes:
>> James Carlson wrote:
>>> Why not have a reference somewhere ("/etc/restricted-shells"?) that
>>> lists the restricted shells? If the user's shell is on that list,
>>> then prohibit changes. If the shell isn't on that list and if the
>>> user has th
Glenn Brunette wrote:
>
> Jim,
>
> James Carlson wrote:
>> Why not have a reference somewhere ("/etc/restricted-shells"?) that
>> lists the restricted shells? If the user's shell is on that list,
>> then prohibit changes. If the shell isn't on that list and if the
>> user has the (by default gr
..
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<http://mail.opensolaris.org/pipermail/security-discuss/attachments/20061110/0688ad5b/attachment.bin>
River Tarnell wrote:
>
> Darren Moffat suggested this would be better implemented as an RBAC
> privilege, which i believe he will documented separately.
Authoirisation != privilege they are different.
Okay for here is my thoughts on how to do this.
I don't believe a user should ever be allowed
bbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<http://mail.opensolaris.org/pipermail/security-discuss/attachments/20061110/e616ea23/attachment.bin>
Darren J Moffat writes:
> A user can never change either own shell if it is not listed in /etc/shells.
>
> A user must have solaris.usermgr.write.shell to change their shell.
> Users will have this authorisation by default.
This sounds almost perfect.
What happens if I currently have a shell tha
James Carlson wrote:
> Glenn Brunette writes:
>> James Carlson wrote:
>>> Why not have a reference somewhere ("/etc/restricted-shells"?) that
>>> lists the restricted shells? If the user's shell is on that list,
>>> then prohibit changes. If the shell isn't on that list and if the
>>> user has
Glenn Brunette writes:
> James Carlson wrote:
> > Why not have a reference somewhere ("/etc/restricted-shells"?) that
> > lists the restricted shells? If the user's shell is on that list,
> > then prohibit changes. If the shell isn't on that list and if the
> > user has the (by default granted) a
Jim,
James Carlson wrote:
> Why not have a reference somewhere ("/etc/restricted-shells"?) that
> lists the restricted shells? If the user's shell is on that list,
> then prohibit changes. If the shell isn't on that list and if the
> user has the (by default granted) authorization to change she
Darren J Moffat writes:
> There are use cases where it would be acceptable for a user to update
> the GECOS entry but not change their shell (say they have a restricted
> shell or profile shell). This means the policy also needs to be at the
> level of the data item that is being changed.
>
>
12 matches
Mail list logo
