Re: [ALFS Trac] #1739: Reorder or remove deleting the lfs user

On Fri, Dec 27, 2024 at 7:54 AM Bruce Dubbs <[email protected]> wrote:
>
> On 12/27/24 07:28, jeremy wiig wrote:
> > On Thu, Dec 26, 2024 at 10:07 PM Bruce Dubbs
> > <[email protected]> wrote:
> >>
> >> On 12/22/24 11:10, ALFS Trac ([email protected] via alfs-discuss Mailing
> >> List) wrote:
> >>> #1739: Reorder or remove deleting the lfs user
> >>> --------------------+------------------------------
> >>>    Reporter:  xry111  |       Owner:  Pierre Labastie
> >>>        Type:  defect  |      Status:  accepted
> >>>    Priority:  normal  |   Milestone:
> >>> Component:  jhalfs  |     Version:  GIT
> >>>    Severity:  normal  |  Resolution:
> >>>    Keywords:          |
> >>> --------------------+------------------------------
> >>> Comment (by Douglas R. Reno):
> >>>
> >>>    Replying to [comment:3 Pierre Labastie]:
> >>>    > I've come to this:
> >>>    > - If a user with name ''lfs'' exists on the system:
> >>>    >   -  rename that user to ''lfsxxx'', and move its home to
> >>>    '''/home/lfs.XXX'''. This means that if a user with name ''lfsxxx'' is
> >>>    already on the system, we must delete it, possibly after asking  (but I do
> >>>    not like that, because it means jhalfs cannot be run unattended).
> >>>    >   -  create a new ''lfs'' user with book instructions
> >>>    >   -  leave everything as is, but warn at the end of the jhalfs run that
> >>>    there is a new user and the old one has changed name
> >>>    >
> >>>    > - if there is no user with name ''lfs'':
> >>>    >   -  create it with book instructions
> >>>    >   -  leave it as is, but warn at the end of the jhalfs run that there is
> >>>    a new user
> >>>    >
> >>>    > Please comment...
> >>>
> >>>    This approach sounds really good to me. I think we probably shouldn't ask
> >>>    since most users shouldn't have anything in /home/lfs other than the files
> >>>    we create, and we want jhalfs to be completely automated. A lot of us
> >>>    editors that use jhalfs for testing LFS have a 'lfs' user kept around, so
> >>>    this would probably be the best way for us editors as well. I think a
> >>>    notification at the end would be helpful as well
> >>>
> >>>    This also fixes the issue that I run into when building a new system where
> >>>    I don't realize that the lfs user hasn't been created yet, and jhalfs
> >>>    fails because of it
> >>
> >> I'm coming into this a little late, but I think the lfs user should be deleted at the
> >> jhalfs install phase before the LFS build if it exists.  At that point the user is
> >> always present. If desired, a question can be asked if saving the lfs user is
> >> desired, but I just checked and the only things in $HOME/lfs is .bash_profile and
> >> .bashrc.
> >>
> >> The other option of automatically deleting the lfs user when entering chroot in
> >> Chapter 7 is also acceptable.  From a manual build standpoint the only reason to
> >> leave it is if the user made a mistake and has to go back to Chapter 5 or 6.
> >>
> >> We run into similar issues if the user un-mounts the virtual file systems and then
> >> forgets to re-mount them.
> >>
> >>     -- Bruce
> >>
> >
> > What about creating random lfs user to avoid possible interference
> > with existing host:
> >
> > lfsuser=lfsuser$RANDOM
> > useradd $lfsuser
> > echo $lfsuser > lfsuser
> >
> > . . .
> >
> > userdel $(cat lfsuser)
>
> That makes things more complicated.  We want to keep things simple.  The lfs user in
> the book is there to prevent someone from corrupting the host operating system.  It's
> not there for general use.  When it's job is done, it should be deleted just like we
> delete the tester account in 8.85. Cleaning Up.  The difference of course is that
> tester is created and deleted in chroot and lfs is created in the environment of the
> host system.
>
>    -- Bruce

It doesn't appear to be that complicated as most of the code is
already there. Would only really need to modify the LUSER and LGROUP
variable assignments in the makefile. I would attempt the changes
myself if I wasn't already hilt deep in an lfs package management
project :)

But I do agree that some onus should be placed on the user rather than
having the tool try to accommodate multiple edge cases. IMO the
simplest case would be for the tool to create and delete the lfs user
for itself. If the system already has an lfs user that is an error. It
is up to the user to correct it, and the tool will not run until they
do.

-- 
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page