Re: [LEDE-DEV] Procd and askconsole

2016-09-20 Thread John Crispin
ok, lets do that then. i'll have a look at your patch from last week
during the day

John

On 20/09/2016 09:49, Lebleu Pierre wrote:
> Hi John,
> 
> Indeed, I already tried that solution with the default shadow :
> --- a/package/base-files/files/etc/shadow 
>   
>  
> +++ b/package/base-files/files/etc/shadow 
>   
>  
> @@ -1,4 +1,4 @@   
>   
>  
> -root::0:0:9:7::: 
>   
>  
> +root:*:0:0:9:7:::
>   
>  
>  daemon:*:0:0:9:7:::  
>   
>  
>  ftp:*:0:0:9:7::: 
>   
>  
>  network:*:0:0:9:7:::  
> 
> Indeed, it works.
> Until my custom script is called, nobody is able to login.
> But, I think it will be better to have an inittab entry when everything is 
> set like the old sysvinit.
> 
> Pierre
> 
> -Original Message-
> From: John Crispin [mailto:j...@phrozen.org] 
> Sent: dinsdag 20 september 2016 9:43
> To: Lebleu Pierre <pierre.leb...@technicolor.com>; 
> lede-dev@lists.infradead.org
> Subject: Re: [LEDE-DEV] Procd and askconsole
> 
> Hi Pierre,
> 
> the bahaviour you are observing is actually by design. would it be an option 
> to ship a default unknown password on your device. that way login simply wont 
> work until you have set you custom per-device password. you could then do so 
> as the last step of your customs scripts.
> 
> would that be an option ?
> 
>   John
> 
> On 20/09/2016 09:40, Lebleu Pierre wrote:
>> Hi John,
>>
>> Thank you for your answer.
>>
>> I tried your solution but it seems not to work or it does not do what I want.
>> Indeed, the password is one thing but there is also the fact that the system 
>> is not ready (the scripts are still running).
>> As we can see, the hostname is not even set. I would like to allow the 
>> user login only when everything is ready, because the filesystem is about to 
>> be modified.
>>
>> Cheers,
>>
>>
>> Pierre
>>
>> -Original Message-
>> From: John Crispin [mailto:j...@phrozen.org]
>> Sent: vrijdag 16 september 2016 11:18
>> To: Lebleu Pierre <pierre.leb...@technicolor.com>; 
>> lede-dev@lists.infradead.org
>> Subject: Re: [LEDE-DEV] Procd and askconsole
>>
>>
>>
>> On 16/09/2016 10:48, Lebleu Pierre wrote:
>>> Hi all,
>>>
>>> I am new to this mailing list and I would like to present me as Pierre.
>>>
>>> I recently play a bit with procd and I found an "issue". Indeed, if I 
>>> do a factory reset, I am able to login as root without login. I have 
>>> some scripts in /etc/uci-defaults and one of them set the password 
>>> for the root account. So, this behaviour looks like to me a bug.
>>>
>>> For my understanding, when procd reaches STATE_INIT, it runs the 
>>> inittab and one of them is "askconsole". The problem is the system is 
>>> not completely ready to receive the user : the hostname is not even 
>>> set.
>>>
>>> In the old sysvinit, the inittab contains an entry called "bootwait"
>>> wich is executed after the termination of init (eg : "/etc/rc.d").
>>> I purpose to move the "askconsole" entry to STATE_RUNNING or to 
>>> create a new entry called "askconsolewait" in order to keep backward 
>>> compatibility.
>>>
>>> diff --git a/inittab.c b/inittab.c
>>>

Re: [LEDE-DEV] Procd and askconsole

2016-09-20 Thread Lebleu Pierre
Hi John,

Indeed, I already tried that solution with the default shadow :
--- a/package/base-files/files/etc/shadow   

 
+++ b/package/base-files/files/etc/shadow   

 
@@ -1,4 +1,4 @@ 

 
-root::0:0:9:7:::   

 
+root:*:0:0:9:7:::  

 
 daemon:*:0:0:9:7:::

 
 ftp:*:0:0:9:7:::   

 
 network:*:0:0:9:7:::  

Indeed, it works.
Until my custom script is called, nobody is able to login.
But, I think it will be better to have an inittab entry when everything is set 
like the old sysvinit.

Pierre

-Original Message-
From: John Crispin [mailto:j...@phrozen.org] 
Sent: dinsdag 20 september 2016 9:43
To: Lebleu Pierre <pierre.leb...@technicolor.com>; lede-dev@lists.infradead.org
Subject: Re: [LEDE-DEV] Procd and askconsole

Hi Pierre,

the bahaviour you are observing is actually by design. would it be an option to 
ship a default unknown password on your device. that way login simply wont work 
until you have set you custom per-device password. you could then do so as the 
last step of your customs scripts.

would that be an option ?

John

On 20/09/2016 09:40, Lebleu Pierre wrote:
> Hi John,
> 
> Thank you for your answer.
> 
> I tried your solution but it seems not to work or it does not do what I want.
> Indeed, the password is one thing but there is also the fact that the system 
> is not ready (the scripts are still running).
> As we can see, the hostname is not even set. I would like to allow the 
> user login only when everything is ready, because the filesystem is about to 
> be modified.
> 
> Cheers,
> 
> 
> Pierre
> 
> -Original Message-
> From: John Crispin [mailto:j...@phrozen.org]
> Sent: vrijdag 16 september 2016 11:18
> To: Lebleu Pierre <pierre.leb...@technicolor.com>; 
> lede-dev@lists.infradead.org
> Subject: Re: [LEDE-DEV] Procd and askconsole
> 
> 
> 
> On 16/09/2016 10:48, Lebleu Pierre wrote:
>> Hi all,
>>
>> I am new to this mailing list and I would like to present me as Pierre.
>>
>> I recently play a bit with procd and I found an "issue". Indeed, if I 
>> do a factory reset, I am able to login as root without login. I have 
>> some scripts in /etc/uci-defaults and one of them set the password 
>> for the root account. So, this behaviour looks like to me a bug.
>>
>> For my understanding, when procd reaches STATE_INIT, it runs the 
>> inittab and one of them is "askconsole". The problem is the system is 
>> not completely ready to receive the user : the hostname is not even 
>> set.
>>
>> In the old sysvinit, the inittab contains an entry called "bootwait"
>> wich is executed after the termination of init (eg : "/etc/rc.d").
>> I purpose to move the "askconsole" entry to STATE_RUNNING or to 
>> create a new entry called "askconsolewait" in order to keep backward 
>> compatibility.
>>
>> diff --git a/inittab.c b/inittab.c
>> index ae2c431..2d590e4 100644
>> --- a/inittab.c
>> +++ b/inittab.c
>> @@ -228,6 +228,10 @@ static struct init_handler handlers[] = {
>> .name = "respawn",
>> .cb = rcrespawn,
>> .multi = 1,
>> +   }, {
>> +   .name = "askconsolewait",
>> +   .cb = askconsole,
>> +   .multi = 1,
>> }
>>  };
>>  
>> @@ -251,11 +255,9 @@ void procd_inittab_run(const char *handl

Re: [LEDE-DEV] Procd and askconsole

2016-09-20 Thread Lebleu Pierre
Hi John,

Thank you for your answer.

I tried your solution but it seems not to work or it does not do what I want.
Indeed, the password is one thing but there is also the fact that the system is 
not ready (the scripts are still running).
As we can see, the hostname is not even set. I would like to allow the user 
login only when everything is ready, because
the filesystem is about to be modified.

Cheers,


Pierre

-Original Message-
From: John Crispin [mailto:j...@phrozen.org] 
Sent: vrijdag 16 september 2016 11:18
To: Lebleu Pierre <pierre.leb...@technicolor.com>; lede-dev@lists.infradead.org
Subject: Re: [LEDE-DEV] Procd and askconsole



On 16/09/2016 10:48, Lebleu Pierre wrote:
> Hi all,
> 
> I am new to this mailing list and I would like to present me as Pierre.
> 
> I recently play a bit with procd and I found an "issue". Indeed, if I 
> do a factory reset, I am able to login as root without login. I have 
> some scripts in /etc/uci-defaults and one of them set the password for 
> the root account. So, this behaviour looks like to me a bug.
> 
> For my understanding, when procd reaches STATE_INIT, it runs the 
> inittab and one of them is "askconsole". The problem is the system is 
> not completely ready to receive the user : the hostname is not even 
> set.
> 
> In the old sysvinit, the inittab contains an entry called "bootwait"
> wich is executed after the termination of init (eg : "/etc/rc.d").
> I purpose to move the "askconsole" entry to STATE_RUNNING or to create 
> a new entry called "askconsolewait" in order to keep backward 
> compatibility.
> 
> diff --git a/inittab.c b/inittab.c
> index ae2c431..2d590e4 100644
> --- a/inittab.c
> +++ b/inittab.c
> @@ -228,6 +228,10 @@ static struct init_handler handlers[] = {
> .name = "respawn",
> .cb = rcrespawn,
> .multi = 1,
> +   }, {
> +   .name = "askconsolewait",
> +   .cb = askconsole,
> +   .multi = 1,
> }
>  };
>  
> @@ -251,11 +255,9 @@ void procd_inittab_run(const char *handler)
>  
> list_for_each_entry(a, , list)
> if (!strcmp(a->handler->name, handler)) {
> -   if (a->handler->multi) {
> -   a->handler->cb(a);
> -   continue;
> -   }
> a->handler->cb(a);
> +   if (a->handler->multi)
> +   continue;
> break;
> }
>  }
> diff --git a/state.c b/state.c
> index 4ad9e2d..fe37419 100644
> --- a/state.c
> +++ b/state.c
> @@ -128,6 +128,7 @@ static void state_enter(void)
>  
> case STATE_RUNNING:
> LOG("- init complete -\n");
> +   procd_inittab_run("askconsolewait");
> break;
>  
> case STATE_SHUTDOWN:
> 
> What is your view ? Thank you.
> 
> Cheers,
> 
> Pierre
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

Hi Pierre,

just to be clear, you mean that there is a short timeslot between 
inittab/askconsole and uci-defaults during which a passwordless login is 
possible and you would liek to prevent this ?

if i understood the problem corretly please simply set

ttylogin=1 here ->

https://git.lede-project.org/?p=source.git;a=blob;f=package/base-files/files/bin/config_generate;h=80ed61b9e2dabf6f2f99102345be3da60097af3e;hb=HEAD#l231

that should make the image boot with password login required even if no 
password is set.

the normal use case is that one flashes, enables the flag and then upon second 
bootup the unit will require a login. in your use case you already want the 
password protection on the very first boot i think

John


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev


Re: [LEDE-DEV] Procd and askconsole

2016-09-16 Thread John Crispin


On 16/09/2016 17:59, Alberto Bursi wrote:
> 
> 
> On 09/16/2016 10:48 AM, Lebleu Pierre wrote:
>> Hi all,
>>
>> I am new to this mailing list and I would like to present me as Pierre.
>>
>> I recently play a bit with procd and I found an "issue". Indeed, if I do
>> a factory reset, I am able to login as root without login. I have some
>> scripts in /etc/uci-defaults and one of them set the password for the
>> root account. So, this behaviour looks like to me a bug.
>>
>> For my understanding, when procd reaches STATE_INIT, it runs
>> the inittab and one of them is "askconsole". The problem is the system
>> is not completely ready to receive the user : the hostname is not even
>> set.
>>
>> In the old sysvinit, the inittab contains an entry called "bootwait"
>> wich is executed after the termination of init (eg : "/etc/rc.d").
>> I purpose to move the "askconsole" entry to STATE_RUNNING or to create
>> a new entry called "askconsolewait" in order to keep backward
>> compatibility.
>>
>> diff --git a/inittab.c b/inittab.c
>> index ae2c431..2d590e4 100644
>> --- a/inittab.c
>> +++ b/inittab.c
>> @@ -228,6 +228,10 @@ static struct init_handler handlers[] = {
>>  .name = "respawn",
>>  .cb = rcrespawn,
>>  .multi = 1,
>> +   }, {
>> +   .name = "askconsolewait",
>> +   .cb = askconsole,
>> +   .multi = 1,
>>  }
>>   };
>>   
>> @@ -251,11 +255,9 @@ void procd_inittab_run(const char *handler)
>>   
>>  list_for_each_entry(a, , list)
>>  if (!strcmp(a->handler->name, handler)) {
>> -   if (a->handler->multi) {
>> -   a->handler->cb(a);
>> -   continue;
>> -   }
>>  a->handler->cb(a);
>> +   if (a->handler->multi)
>> +   continue;
>>  break;
>>  }
>>   }
>> diff --git a/state.c b/state.c
>> index 4ad9e2d..fe37419 100644
>> --- a/state.c
>> +++ b/state.c
>> @@ -128,6 +128,7 @@ static void state_enter(void)
>>   
>>  case STATE_RUNNING:
>>  LOG("- init complete -\n");
>> +   procd_inittab_run("askconsolewait");
>>  break;
>>   
>>  case STATE_SHUTDOWN:
>>
>> What is your view ? Thank you.
>>
>> Cheers,
>>
>> Pierre
>>
> Is this fixing this issue ? 
> https://bugs.lede-project.org/index.php?do=details_id=123
> 

no, totally unrelated, i have a fix for #123 in my local tree already
though. need to give it a bit more testing though.


> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
> 

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev