adduser/passwd: too long username

Laszlo Papp lpapp at kde.org
Tue Aug 5 15:05:11 UTC 2014


On Tue, Aug 5, 2014 at 3:13 PM, Laszlo Papp <lpapp at kde.org> wrote:

>
>
>
> On Tue, Aug 5, 2014 at 3:06 PM, tito <farmatito at tiscali.it> wrote:
>
>> On Tuesday 05 August 2014 15:21:49 you wrote:
>> > On Tue, Aug 5, 2014 at 2:14 PM, Laszlo Papp <lpapp at kde.org> wrote:
>> >
>> > >
>> > >
>> > >
>> > > On Tue, Aug 5, 2014 at 2:06 PM, tito <farmatito at tiscali.it> wrote:
>> > >
>> > >> On Tuesday 05 August 2014 14:47:53 you wrote:
>> > >> > On Tue, Aug 5, 2014 at 1:42 PM, tito <farmatito at tiscali.it> wrote:
>> > >> >
>> > >> > > On Tuesday 05 August 2014 14:27:57 you wrote:
>> > >> > > > I disagree. There is nothing to reject here. It fixes _my
>> issue_ at
>> > >> hand.
>> > >> > > > If you want to fix other bugs in your system that you are
>> facing in
>> > >> > > > reality, by all means, fix them in a separate change.
>> > >> > > >
>> > >> > > > I definitely do not agree with dynamically allocated buffer
>> for the
>> > >> > > simple
>> > >> > > > reasons of:
>> > >> > > >
>> > >> > > > 1) Slow.
>> > >> > > > 2) You would still need a maximum anyway.
>> > >> > > > 3) Needless code complication.
>> > >> > > >
>> > >> > > > Let us keep things simple and good, you know the good old KISS
>> > >> principle.
>> > >> > > >
>> > >> > > > P.S.: please do not bikeshed.
>> > >> > > >
>> > >> > > >
>> > >> > > > On Tue, Aug 5, 2014 at 1:17 PM, tito <farmatito at tiscali.it>
>> wrote:
>> > >> > > >
>> > >> > > > > On Tuesday 05 August 2014 12:46:08 you wrote:
>> > >> > > > > > Here is my tested fix without being to debug the busybox
>> code,
>> > >> so
>> > >> > > only
>> > >> > > > > code
>> > >> > > > > > reading and understanding were my friends:
>> > >> > > > > >
>> > >> > > > > > commit 9610650b6ce2a4c1904f78a2dcdb47cad3d2e3d1
>> > >> > > > > > Author: Laszlo Papp <lpapp at kde.org>
>> > >> > > > > > Date:   Tue Aug 5 11:42:24 2014 +0100
>> > >> > > > > >
>> > >> > > > > >     Allow 256 bytes long usernames as per Unix standards
>> > >> (usually)
>> > >> > > > > >
>> > >> > > > > > diff --git a/libpwdgrp/pwd_grp.c b/libpwdgrp/pwd_grp.c
>> > >> > > > > > index 2060d78..368c252 100644
>> > >> > > > > > --- a/libpwdgrp/pwd_grp.c
>> > >> > > > > > +++ b/libpwdgrp/pwd_grp.c
>> > >> > > > > > @@ -23,8 +23,8 @@
>> > >> > > > > >
>> > >> > >
>> > >>
>>  /**********************************************************************/
>> > >> > > > > >  /* Sizes for statically allocated buffers. */
>> > >> > > > > >
>> > >> > > > > > -#define PWD_BUFFER_SIZE 256
>> > >> > > > > > -#define GRP_BUFFER_SIZE 256
>> > >> > > > > > +#define PWD_BUFFER_SIZE LOGIN_NAME_MAX+256
>> > >> > > > > > +#define GRP_BUFFER_SIZE LOGIN_NAME_MAX+256
>> > >> > > > > >
>> > >> > > > > >
>> > >> > >
>> > >>
>>  /**********************************************************************/
>> > >> > > > > >  /* Prototypes for internal functions. */
>> > >> > > > > >
>> > >> > > > >
>> > >> > > > > Hi,
>> > >> > > > > yes I've thought also about this solution but rejected it
>> because:
>> > >> > > > >
>> > >> > > > > 1) there will not be enough space to hold the home dir if
>> named
>> > >> the
>> > >> > > same
>> > >> > > > > as the user
>> > >> > > > >     so you need at least:
>> > >> > > > >
>> > >> > > > > #define PWD_BUFFER_SIZE LOGIN_NAME_MAX+ 6 (for home) +
>> > >> LOGIN_NAME_MAX
>> > >> > > (or
>> > >> > > > > PATH_MAX?) + 256 (for the rest)
>> > >> > > > >
>> > >> > > > >    yet this might not be enough as in my passwd file I see a
>> 101
>> > >> char
>> > >> > > long
>> > >> > > > > passwd.
>> > >> > > > >    Add  the gecos fields (arbitrary lenght)  to it and the
>> default
>> > >> > > shell
>> > >> > > > > and we are short on space again.
>> > >> > > > >
>> > >> > > > > 2) same for #define GRP_BUFFER_SIZE LOGIN_NAME_MAX+256:
>> > >> > > > >     here you need to take into account the group member list
>> with
>> > >> > > > >     an arbitrary number of members:
>> > >> > > > >
>> > >> > > > >
>> > >> > > > >     #define GRP_BUFFER_SIZE LOGIN_NAME_MAX+256+
>> LOGIN_NAME_MAX*n:
>> > >> > > > >
>> > >> > > > > The only clean solution to fix it forever is dynamically
>> allocated
>> > >> > > buffers
>> > >> > > > > created at the time you read in the line from the passwd
>> files.
>> > >> > > > >
>> > >> > > > > Ciao,
>> > >> > > > > Tito
>> > >> > > > >
>> > >> > > > >
>> > >> > > > > P.S.: please don't top post.
>> > >> > > > >
>> > >> > > > >
>> > >> > > > > >
>> > >> > > > > > On Tue, Aug 5, 2014 at 11:22 AM, Laszlo Papp <
>> lpapp at kde.org>
>> > >> wrote:
>> > >> > > > > >
>> > >> > > > > > > Yeah, mayhaps... Thanks for the prompt reply. I tried to
>> > >> debug the
>> > >> > > > > code,
>> > >> > > > > > > but the busybox code here is a bit messy heavily abusing
>> > >> macros in
>> > >> > > C
>> > >> > > > > and
>> > >> > > > > > > all that. It ain't easy I must confess!
>> > >> > > > > > >
>> > >> > > > > > > For instance, see this section:
>> > >> > > > > > >
>> > >> > > > > > >
>> http://git.busybox.net/busybox/tree/libpwdgrp/pwd_grp.c#n227
>> > >> > > > > > >
>> > >> > > > > > > The _source_ is included several times always getting a
>> new
>> > >> meaning
>> > >> > > > > based
>> > >> > > > > > > on some defines... Now, check this function:
>> > >> > > > > > >
>> > >> > > > > > >
>> > >> > >
>> http://git.busybox.net/busybox/tree/libpwdgrp/pwd_grp_internal.c#n20
>> > >> > > > > > >
>> > >> > > > > > > "resultbuf" will be always different depending on which
>> > >> include it
>> > >> > > is.
>> > >> > > > > > > Since it is failing at the pw_name check in there, I
>> wanted to
>> > >> > > print it
>> > >> > > > > > > out, but no easy joy there as printing it like that will
>> yield
>> > >> > > > > compilation
>> > >> > > > > > > error when the file is being included next time from
>> above.
>> > >> > > > > > >
>> > >> > > > > > > Right, I thought instead of doing some "#if a == b"
>> hackery,
>> > >> > > debugging
>> > >> > > > > > > would be easier, BUT:
>> > >> > > > > > >
>> > >> > > > > > > 1) The default build is stripped, yuck!
>> > >> > > > > > >
>> > >> > > > > > > 2) The unstripped build cannot locate the symbols (*).
>> > >> > > > > > >
>> > >> > > > > > > So, I am giving up on this for now; this is not the type
>> of
>> > >> source
>> > >> > > code
>> > >> > > > > > > that is so pleasant to work with. ;-)
>> > >> > > > > > >
>> > >> > > > > > > Cheers, L.
>> > >> > > > > > >
>> > >> > > > > > > * (gdb) b main
>> > >> > > > > > >
>> > >> > > > > > > Breakpoint 2 at 0x407c71
>> > >> > > > > > > (gdb) r
>> > >> > > > > > > Starting program:
>> > >> /home/lpapp/Projects/busybox/busybox_unstripped
>> > >> > > > > deluser
>> > >> > > > >
>> > >> > >
>> > >>
>> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> > >> > > > > > > warning: Could not load shared library symbols for
>> > >> linux-vdso.so.1.
>> > >> > > > > > > Do you need "set solib-search-path" or "set sysroot"?
>> > >> > > > > > >
>> > >> > > > > > > Breakpoint 2, 0x0000000000407c71 in main ()
>> > >> > > > > > > (gdb) list
>> > >> > > > > > > No symbol table is loaded.  Use the "file" command.
>> > >> > > > > > > (gdb)
>> > >> > > > > > >
>> > >> > > > > > >
>> > >> > > > > > >
>> > >> > > > > > > On Mon, Aug 4, 2014 at 10:40 PM, tito <
>> farmatito at tiscali.it>
>> > >> > > wrote:
>> > >> > > > > > >
>> > >> > > > > > >> On Monday 04 August 2014 19:06:39 Laszlo Papp wrote:
>> > >> > > > > > >> > Hi,
>> > >> > > > > > >> >
>> > >> > > > > > >> > sudo busybox adduser
>> > >> > > > > > >> >
>> > >> > > > > > >>
>> > >> > > > >
>> > >> > >
>> > >>
>> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> > >> > > > > > >> > passwd: unknown user
>> > >> > > > > > >> >
>> > >> > > > > > >>
>> > >> > > > >
>> > >> > >
>> > >>
>> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> > >> > > > > > >> >
>> > >> > > > > > >> > Yet, the user is created in /etc/shadow:
>> > >> > > > > > >> >
>> > >> > > > > > >> >
>> > >> > > > > > >>
>> > >> > > > >
>> > >> > >
>> > >>
>> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff:!:16286:0:99999:7:::
>> > >> > > > > > >> >
>> > >> > > > > > >> > This is at least one issue, but there is another here:
>> > >> > > > > > >> >
>> > >> > > > > > >> > sudo busybox deluser
>> > >> > > > > > >> >
>> > >> > > > > > >>
>> > >> > > > >
>> > >> > >
>> > >>
>> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> > >> > > > > > >> > deluser: unknown user
>> > >> > > > > > >> >
>> > >> > > > > > >>
>> > >> > > > >
>> > >> > >
>> > >>
>> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> > >> > > > > > >> >
>> > >> > > > > > >> > So, basically, once you create that long username, you
>> > >> cannot
>> > >> > > > > remove it
>> > >> > > > > > >> > anymore with busybox and it keeps polluting your
>> system.
>> > >> > > > > > >> >
>> > >> > > > > > >> > You have to gain other means to clean up! I am using
>> this
>> > >> > > version
>> > >> > > > > over
>> > >> > > > > > >> here:
>> > >> > > > > > >> >
>> > >> > > > > > >> > BusyBox v1.22.1 (2014-06-02 14:47:37 MSK) multi-call
>> > >> binary.
>> > >> > > > > > >> >
>> > >> > > > > > >> > Could you please look into this and potentially fix
>> it?
>> > >> Thanks
>> > >> > > in
>> > >> > > > > > >> advance.
>> > >> > > > > > >> >
>> > >> > > > > > >> > Cheers, L.
>> > >> > > > > > >> >
>> > >> > > > > > >> Hi,
>> > >> > > > > > >> if disabling libb's internal pwd/grp lib and by jumping
>> > >> through
>> > >> > > some
>> > >> > > > > hops
>> > >> > > > > > >> it
>> > >> > > > > > >> works for me:
>> > >> > > > > > >>
>> > >> > > > > > >> I need to add the group first as my system's groupadd
>> command
>> > >> > > called
>> > >> > > > > by
>> > >> > > > > > >> bb's adduser
>> > >> > > > > > >> supports only groupnames of max 32 chars.
>> > >> > > > > > >>
>> > >> > > > > > >> ./busybox addgroup
>> > >> > > > > > >>
>> > >> > > > >
>> > >> > >
>> > >>
>> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> > >> > > > > > >> ./busybox adduser
>> > >> > > > > > >>
>> > >> > > > >
>> > >> > >
>> > >>
>> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> > >> > > > > > >> -G
>> > >> > > > > > >>
>> > >> > > > >
>> > >> > >
>> > >>
>> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> > >> > > > > > >> Adding user
>> > >> > > > > > >>
>> > >> > > > >
>> > >> > >
>> > >>
>> `fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff'
>> > >> > > > > > >> to group
>> > >> > > > > > >>
>> > >> > > > >
>> > >> > >
>> > >>
>> `fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff'
>> > >> > > > > > >> ...
>> > >> > > > > > >> Adding user
>> > >> > > > > > >>
>> > >> > > > >
>> > >> > >
>> > >>
>> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> > >> > > > > > >> to group
>> > >> > > > > > >>
>> > >> > > > >
>> > >> > >
>> > >>
>> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> > >> > > > > > >> Done.
>> > >> > > > > > >> Enter new UNIX password:
>> > >> > > > > > >> Retype new UNIX password:
>> > >> > > > > > >> passwd: password updated successfully
>> > >> > > > > > >>
>> > >> > > > > > >> and then I could also delete it:
>> > >> > > > > > >>
>> > >> > > > > > >> ./busybox deluser
>> > >> > > > > > >>
>> > >> > > > >
>> > >> > >
>> > >>
>> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> > >> > > > > > >> ./busybox delgroup
>> > >> > > > > > >>
>> > >> > > > >
>> > >> > >
>> > >>
>> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> > >> > > > > > >> delgroup: unknown group
>> > >> > > > > > >>
>> > >> > > > >
>> > >> > >
>> > >>
>> fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>> > >> > > > > > >>
>> > >> > > > > > >> (deluser correctly deleted also the group)
>> > >> > > > > > >>
>> > >> > > > > > >> I suspect that the buffer size used in
>> libbpwdgrp/pwd_grp.c
>> > >> is to
>> > >> > > > > small:
>> > >> > > > > > >>
>> > >> > > > > > >> #define PWD_BUFFER_SIZE 256
>> > >> > > > > > >> #define GRP_BUFFER_SIZE 256
>> > >> > > > > > >>
>> > >> > > > > > >> as it is meant for the whole struct pw passwd (or
>> struct gr
>> > >> group)
>> > >> > > > > fields
>> > >> > > > > > >> which could be easily be bigger:
>> > >> > > > > > >>
>> > >> > > > > > >> grep ffff* /etc/shadow | wc
>> > >> > > > > > >>       1       1     240
>> > >> > > > > > >> grep ffff* /etc/passwd | wc
>> > >> > > > > > >>       1       2     286
>> > >> > > > > > >>
>> > >> > > > > > >> I think that the buffers' size must be increased for
>> example
>> > >> to:
>> > >> > > > > > >>
>> > >> > > > > > >> #define PWD_BUFFER_SIZE
>> LOGIN_NAME_MAX+LOGIN_NAME_MAX+256
>> > >> > > > > > >>
>> > >> > > > > > >> we need one LOGIN_NAME_MAX size for the login and one
>> more
>> > >> for the
>> > >> > > > > home
>> > >> > > > > > >> dir
>> > >> > > > > > >> if same as login, plus 256 for the remaining data
>> (passwd,
>> > >> gecos,
>> > >> > > > > shell,
>> > >> > > > > > >> etc).
>> > >> > > > > > >>
>> > >> > > > > > >> #define GRP_BUFFER_SIZE
>>  LOGIN_NAME_MAX+256+LOGIN_NAME_MAX*n
>> > >> (?)
>> > >> > > > > > >>
>> > >> > > > > > >> we need one LOGIN_NAME_MAX size for the group name (for
>> > >> which we
>> > >> > > > > > >> actually enforce the same size as for the username)
>> plus 256
>> > >> for
>> > >> > > the
>> > >> > > > > > >> remaining data
>> > >> > > > > > >> plus LOGIN_NAME_MAX * n group member names.
>> > >> > > > > > >>
>> > >> > > > > > >> So for my limited understanding using static buffers
>> here is
>> > >> > > rather
>> > >> > > > > > >> difficult
>> > >> > > > > > >> as the size of data is not easily predictable.
>> > >> > > > > > >> I don't know how real libc manages it (maybe realloc on
>> > >> ERANGE?)
>> > >> > > > > > >>
>> > >> > > > > > >> Your particular example for me is fixed by using.
>> > >> > > > > > >>
>> > >> > > > > > >> #define PWD_BUFFER_SIZE 1024
>> > >> > > > > > >>
>> > >> > > > > > >> #define GRP_BUFFER_SIZE 1024
>> > >> > > > > > >>
>> > >> > > > > > >> But to me it seems not an optimal solution,
>> > >> > > > > > >> so other more experienced developers should
>> > >> > > > > > >> take a look at it.
>> > >> > > > > > >>
>> > >> > > > > > >> Hope this helps.
>> > >> > > > > > >> Ciao,
>> > >> > > > > > >> Tito
>> > >> > > > > > >>
>> > >> > > > > > >> PS: in libbbpwdgrp functions we need to check for
>> errors:
>> > >> > > > > > >>
>> > >> > > > > > >>    0 or ENOENT or ESRCH or EBADF or EPERM or ...
>> > >> > > > > > >>               The given name or gid was not found.
>> > >> > > > > > >>
>> > >> > > > > > >>        EINTR  A signal was caught.
>> > >> > > > > > >>
>> > >> > > > > > >>        EIO    I/O error.
>> > >> > > > > > >>
>> > >> > > > > > >>        EMFILE The maximum number (OPEN_MAX) of files
>> was open
>> > >> > > already
>> > >> > > > > in
>> > >> > > > > > >> the calling process.
>> > >> > > > > > >>
>> > >> > > > > > >>        ENFILE The maximum number of files was open
>> already
>> > >> in the
>> > >> > > > > system.
>> > >> > > > > > >>
>> > >> > > > > > >>        ENOMEM Insufficient memory to allocate group
>> > >> structure.
>> > >> > > > > > >>
>> > >> > > > > > >>        ERANGE Insufficient buffer space supplied.
>> > >> > > > > > >>
>> > >> > > > > > >> as for example the xgroup_study function in the addgroup
>> > >> applet
>> > >> > > > > > >> assigns a wrong gid if getgrgid fails for example for
>> ERANGE
>> > >> > > > > > >>
>> > >> > > > > > >>         /* Check if the desired gid is free
>> > >> > > > > > >>          * or find the first free one */
>> > >> > > > > > >>         while (1) {
>> > >> > > > > > >>                 printf("gid %d\n", g->gr_gid);
>> > >> > > > > > >>                 if (!getgrgid(g->gr_gid)) {
>> > >> > > > > > >>                         return; /* found free group:
>> return
>> > >> */
>> > >> > > > > > >>                 }
>> > >> > > > > > >>
>> > >> > > > > > >>
>> > >> > > Hi,
>> > >> > > I doubt it fixes your issue
>> > >> >
>> > >> >
>> > >> > What you are basically telling me here that I submitted untested
>> changes
>> > >> > for my use cases, directly or indirectly. Either way, I refuse this
>> > >> claim
>> > >> > since I _did_ test the change for my use case.
>> > >> >
>> > >> >
>> > >> > >  because I tested the same fix and it did in fact
>> > >> >
>> > >> > fail. Please test:
>> > >> > >
>> > >> > > 1) ./busybox addgroup LONGUSERNAME   (this fails in subtle ways
>> as a
>> > >> > > already in use gid is assigned)
>> > >> > > 2) ./busybox adduser LONGUSERNAME -G LONGUSERNAME
>> > >> > > 3) ./busybox deluser LONGUSERNAME
>> > >> > > 4) ./busybox delgroup LONGUSERNAME
>> > >> > >
>> > >> >
>> > >> > I do not see how this is any relevant to my initial steps. This is
>> a
>> > >> > completely different test step with a different issue. As I said
>> > >> earlier,
>> > >> > please welcome contributors rather than being blocker just because
>> they
>> > >> fix
>> > >> > one particular and real bug, and not every "imaginary" use case
>> that can
>> > >> > just exist in the world out there.
>> > >> >
>> > >>
>> > >> Hi,
>> > >> there is nothing imaginary here, i just would like to point out that
>> > >> due to the fact that busybox adduser program by default creates
>> > >> a home dir with the same name as the user the buffer size you
>> > >> propose in your fix may not be big enough to hold all the data
>> > >> and that this fact will affect also other commands that use
>> > >> the functions in libbbpwdgrp in subtle ways.
>> > >> I of course welcome you as a contributor and by the way I have
>> > >> no decisional power to accept or reject your patches (which is fine
>> > >> for me), but nonetheless sometimes I disagree with you for the sake
>> > >> of cleaner solutions (from my point of view).
>> > >>
>> > >
>> > > This script disagrees with you:
>> > >
>> > > #!/bin/bash
>> > >
>> > > USERNAME='e'
>> > > for i in {1..232}
>> > > do
>> > >     USERNAME+='f'
>> > > done
>> > > echo $USERNAME
>> > >
>> > > ./busybox adduser -D $USERNAME
>> > > ./busybox deluser $USERNAME
>> > >
>> >
>> > Furthermore, I am planning to use -H for now, so I am not in any way
>> > affected by this (other than -H is broken here for some reason because
>> it
>> > does create the home folder in /etc/passwd, but that is discussion for
>> > another thread).
>> Hi,
>>
>> --no-create-home
>>               Do not create the home directory, even if it doesn't exist.
>>
>> #adduser prova --no-create-home
>> Adding user `prova' ...
>> Adding new group `prova' (1005) ...
>> Adding new user `prova' (1004) with group `prova' ...
>> Not creating home directory `/home/prova'.
>> Enter new UNIX password:
>> Retype new UNIX password:
>> passwd: password updated successfully
>> Changing the user information for prova
>> Enter the new value, or press ENTER for the default
>>         Full Name []:
>>         Room Number []:
>>         Work Phone []:
>>         Home Phone []:
>>         Other []:
>> Is the information correct? [Y/n] y
>> # grep prova /etc/passwd
>> prova:x:1004:1005:,,,:/home/prova:/bin/bash
>> #ls -la /home | grep prova
>>
>> This is the expected behaviour. Real adduser on debian does the same.
>>
>
> Please forget about Debian's adduser when discussing it. Different
> distributions have different wrappers, so it is not the main direction. In
> fact, debian even has custom policies in those wrappers. I was
> investigating about it, and it seems even -r (system user) is having that
> passwd entry, which I personally believe _strange_ at this point. I am yet
> to understand why it is done so. In my opinion, it is wrong, at least from
> certain point of view because:
>
> * If you do not intend to create a home directory at this point, but later
> manually, you will end up having the wrong entry in /etc/passwd.
>
> * Even if you never create a home directory, it might whisper that the
> home folder was removed manually by someone. At least, this is a potential
> confusion.
>
> I think at this point - based on my current information -, busybox could
> do better than the desktop tool here. It would not be the first reasonable
> separation from the desktop family (past hint: flexibility about usernames
> and passwords).
>

After a bit of thinking and investigation, I believe this has been a
historical oversight from the GNU tool developers. Here [1] is the
definition of the home entry in the /etc/passwd file:


   1. *Home directory*: The absolute path to the directory the user will be
   in when they log in. If this directory does not exists then users directory
   becomes /

In other words, when you do not create a home folder, it will be "/" by
default, and I think that is the entry or empty should be put into the
/etc/passwd file by default in such cases. When someone intends to create a
home folder later for the same user without deletion and recreation, one
can use usermod with the corresponding option (-d/--home) on desktop which
will modify the /etc/passwd entry, too. So, I do not see any point in the
default "/home/foo" put in /etc/passwd for user "foo" created intentionally
without home directories.

Busybox could have a helper like that later. Do you remember that I was
planning to add support for changing the username before anyway? This could
be tied up with that into one applet or so. I remember you had a very long
and descriptive reply with your ideas, too.

I think it would be much saner behavior than what the desktop util does
without breaking the definition of that entry, while preserving a
potentially smaller footprint, too, in that file. That is also inline with
busybox's goal IMHO.

[1] http://www.cyberciti.biz/faq/understanding-etcpasswd-file-format/


>
> Cheers, L.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20140805/1547c228/attachment-0001.html>


More information about the busybox mailing list