I assume SHA256 (5) was chosen over SHA512 (6) because SHA256 is more widely
available on other UNIX/Linux systems. True?
src/util/distro-import/Makefile.sdiff.html
263 '/^root/{ print
"root:$5$VgppCOxA$ycFmYW4ObRRHhtsGEygDdexk5bugqgSiaSR9niNCouC:14146::";continue}
{print $$0}') >
On 09/30/08 16:35, Joep Vesseur wrote:
> On 09/29/08 22:56, John Sonnenschein wrote:
>> Hey security people
>>
>> I'm fishing for feedback on something. A user can't change his or her
>> own shell in [Open]Solaris.
>
> This is only (for the files repository, i.e. /etc/passwd) because there
> is a
On 09/29/08 22:56, John Sonnenschein wrote:
> Hey security people
>
> I'm fishing for feedback on something. A user can't change his or her
> own shell in [Open]Solaris.
This is only (for the files repository, i.e. /etc/passwd) because there
is an explicit check in passwd.c that prohibits regula
Bart Blanquart wrote:
> On 09/30/08 14:21, James Carlson wrote:
>> John Sonnenschein writes:
>>> putting it in a separate package sufficient, or would an /etc/chsh.deny
>>> file be the preferred method?
>> Neither. I think this ought to be an authorization that can be
>> granted or revoked. Some
James Carlson wrote:
> John Sonnenschein writes:
>> putting it in a separate package sufficient, or would an /etc/chsh.deny
>> file be the preferred method?
>
> Neither. I think this ought to be an authorization that can be
> granted or revoked. Something like:
>
> solaris.admin.usermgr.
On 09/30/08 14:21, James Carlson wrote:
> John Sonnenschein writes:
>> putting it in a separate package sufficient, or would an /etc/chsh.deny
>> file be the preferred method?
>
> Neither. I think this ought to be an authorization that can be
> granted or revoked. Something like:
>
> sol
On Tue 30 Sep 2008 at 11:09AM, Alan Coopersmith wrote:
> Will the ON version of this file be updated as well? I understand doing
> this now in Indiana only to get the change out sooner for more test
> exposure, but this seems like something that should happen in the ON master
> copy, not just Ind
Will the ON version of this file be updated as well? I understand doing
this now in Indiana only to get the change out sooner for more test
exposure, but this seems like something that should happen in the ON master
copy, not just Indiana's copy.
-alan-
Dan Price wrote:
> Hi all,
>
> P
On 09/29/08 23:43, John Sonnenschein wrote:
> putting it in a separate package sufficient, or would an /etc/chsh.deny
> file be the preferred method?
chkauthattr("solaris.admin.self.shell", pw->pw_name) or similar would be
preferable (the name of the authorization is just an example), as that
On Tue, Sep 30, 2008 at 04:35:34PM +0200, Joep Vesseur wrote:
> I'm not opposed to creating a different binary (chsh/chfn), but I'd suggest
> to keep all this functionality in one place (passwd) and create hardlinks
> to it, if possible.
ISTR that's exactly how it works on the BSD versions of pas
Bart Blanquart writes:
> I would propose a different subsection here instead of
> solaris.admin.usermgr, to do with modifying your own data: the ability
> to change all other (shell/gecos) fields should be separate from being
> able to modify your own.
That's even better. Just so long as it's
John Sonnenschein writes:
> putting it in a separate package sufficient, or would an /etc/chsh.deny
> file be the preferred method?
Neither. I think this ought to be an authorization that can be
granted or revoked. Something like:
solaris.admin.usermgr.shell
solaris.admin.userm
John Sonnenschein wrote:
> Mike Gerdts wrote:
> > On Mon, Sep 29, 2008 at 4:07 PM, Gary Winiger 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
13 matches
Mail list logo
