Re: [PATCH] umount: always use umount2 syscall with specified flags

[Denys Vlasenko]

Applied, thanks!
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Denys Vlasenko]

I tested

$ su --version
su (GNU coreutils) 8.17

and it allows su to root w/o asking for password if it is null.

busybox does the same.

If there is the need to disallow people to be able to log in as root,
you should set root password.

If you set password hash to an invalid hash, you can even make people
to be unable to ever login as root - there is no valid password then
(passwd -l does this).
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Re: bug-report: ash: fix a memory leak

[Denys Vlasenko]

On Mon, Sep 28, 2015 at 4:17 AM, Rongqing Li  wrote:
>
>
> On 2014年12月24日 13:53, Rich Felker wrote:
>>
>> On Wed, Dec 24, 2014 at 10:32:19AM +0800, yhu2 wrote:
>>>
>>> The script which triggers the leak:
>>>
>>> while true
>>>do
>>>  while true
>>>do
>>>  break;
>>>  done>> done
>>>
>>> someone had fixed this bug, the commit is:
>>>
>>> http://git.busybox.net/busybox/commit/shell/ash.c?id=4ba6c5d3ba3d2c7922aff6b5c2e73b8325f1cf17
>>>
>>> but this commit results in crash running some shell scripts, so it was
>>> reverted.
>>>
>>>
>>> I am trying to resolve this defect,any commnent would be appreciated!
>>
>>
>> There is no easy fix. The patch you sent is incorrect. The problem is
>> that the "stack model" used for allocation in ash is semantically
>> wrong, and needs to be replaced with a dependency-tree model or
>> something else that can handle freeing one object without freeing all
>> subsequently-allocated objects.
>>
>> As a workaround, it might be possible to code a hack to reuse the
>> existing copy of the string on the allocation stack rather than
>> allocating a new copy whenever an existing copy already exists. This
>> would not solve the general case (e.g. when the redirection uses a
>> different file on each iteration) but it would solve the case above, I
>> think. It might be worth pursuing this approach if nobody is available
>> to work on the proper fix in the near future.
>>


Yes, unfortunately no one is willing to significantly rework ash.c code.

Li, maybe you can use the other shell bbox has, hush?
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Alain Mouette]

Why would you want to completely disable root login?

If it is a security feature, how can it be used? It can be interesting 
to avoid escalating priviledges, but then how to to administrative 
tasks? (assuming ssh root login is disabled too)


Thanks,
Alain


On 01-10-2015 14:39, Denys Vlasenko wrote:

I tested

$ su --version
su (GNU coreutils) 8.17

and it allows su to root w/o asking for password if it is null.

busybox does the same.

If there is the need to disallow people to be able to log in as root,
you should set root password.

If you set password hash to an invalid hash, you can even make people
to be unable to ever login as root - there is no valid password then
(passwd -l does this).
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox



___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Jody Bruchon]

On 10/1/2015 2:42 PM, Alain Mouette wrote:

Why would you want to completely disable root login?

If it is a security feature, how can it be used? It can be interesting
to avoid escalating priviledges, but then how to to administrative
tasks? (assuming ssh root login is disabled too)


Ubuntu disables root logins via both 'login' and 'su' and forces the use 
of 'sudo' to run things as root. I assume that this is what people want 
to exclusively use for privilege escalation when suggesting this feature.


In my case, I have a Linux "rescue" platform which has a blank root 
password because it's unnecessary to force the user to type one in and 
the entire system is designed to run temporarily out of a tmpfs. In my 
case, whether this affects 'su' or 'login', it would be a bug, not a 
feature. As long as it is an optional behavior that I can disable with 
no side effects, I see no reason to argue with making such a feature 
available.


Jody Bruchon
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] su: support denying accounts with blank password

[Rich Felker]

On Thu, Oct 01, 2015 at 03:42:40PM -0300, Alain Mouette wrote:
> Why would you want to completely disable root login?
> 
> If it is a security feature, how can it be used? It can be
> interesting to avoid escalating priviledges, but then how to to
> administrative tasks? (assuming ssh root login is disabled too)

Requiring pubkey-based ssh login is the canonical best-practices way.

Rich
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox