On Tuesday 05 August 2014 17:05:11 you wrote: > On Tue, Aug 5, 2014 at 3:13 PM, Laszlo Papp <lp...@kde.org> wrote: > > > > > > > > > On Tue, Aug 5, 2014 at 3:06 PM, tito <farmat...@tiscali.it> wrote: > > > >> On Tuesday 05 August 2014 15:21:49 you wrote: > >> > On Tue, Aug 5, 2014 at 2:14 PM, Laszlo Papp <lp...@kde.org> wrote: > >> > > >> > > > >> > > > >> > > > >> > > On Tue, Aug 5, 2014 at 2:06 PM, tito <farmat...@tiscali.it> wrote: > >> > > > >> > >> On Tuesday 05 August 2014 14:47:53 you wrote: > >> > >> > On Tue, Aug 5, 2014 at 1:42 PM, tito <farmat...@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 <farmat...@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 <lp...@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 < > >> lp...@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 < > >> farmat...@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,
Hi, it will be "/" only in case the home dir does not exist at login time as the login program does chdir to the home dir else you would be locked out of a broken system (damaged partition mounted to /home, /root folder corrupted on main file system). This is what I understand, not that you should put "/" in the passwd files. Ciao, Tito > 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. > > > _______________________________________________ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
