The summary says most about it. When creating a user with the installer, his home directory has 755 as permissions (in standard security level), when using userdrake on the same system afterwards it's 700. I think both tools should behave in the same way. This was found on Mdv 2010.1/2010.2 but is confirmed on Cauldron.
I reproduce it here, actually, 700 isnât normal for standard policy
CC: (none) => shikamaru
CC: (none) => mageia, pterjanSummary: Installer and userdrake give different permissions to home directories => Installer and userdrake give different permissions to user home directoriesSource RPM: (none) => drakxtools
$HOME should have 700. With 755 everyone can read the files of other users. Directories in $HOME should have 755 but not itself.
CC: (none) => wannespam
It depends of security level AFAIK I want people to access some of my files, for example ~/public_html will not work if you don't have at least 711
Hardware: i586 => AllSeverity: normal => major
but with 700 everyone can read every File. I don't think that there are many people who want this.
I guess you mean with 755. People can only read what they are allowed to read. And with 711 they also have to know the name of the file. Desktop, Documents, ... are not accessible, same for important config files/directories (.ssh, .dbus, .Xauthority, .bash_history, ...), tmp etc
Er and with 711 it's the same. You have only to guess the directories which are in $HOME. - I would test Documents, Music, Pictures, Video, tmp, .config, .kde4, .gnome2 and .mozilla... $HOME shouldn't have an x at the end.
As I said those directories are not accessible even with 755... Their own rights protect them.
Actually so default dirs in ~/ are 700 and some are 755: $ ls -la ~/ total 288 drwxr-xr-x 29 lx lx 4096 Apr 2 11:27 ./ drwxr-xr-x 10 root root 4096 Mar 30 16:57 ../ -rw------- 1 lx lx 977 Apr 2 11:55 .bash_history -rw-r--r-- 1 lx lx 24 Mar 15 19:05 .bash_logout -rw-r--r-- 1 lx lx 191 Mar 15 19:05 .bash_profile -rw-r--r-- 1 lx lx 124 Mar 15 19:05 .bashrc drwx------ 5 lx lx 4096 Apr 1 23:49 .cache/ drwxr-xr-x 12 lx lx 4096 Apr 2 11:25 .config/ drwx------ 3 lx lx 4096 Mar 26 10:28 .dbus/ drwxr-xr-x 2 lx lx 4096 Mar 26 10:30 Desktop/ -rw-r--r-- 1 lx lx 27 Apr 1 23:25 .dmrc drwxr-xr-x 2 lx lx 4096 Mar 26 10:28 Documents/ drwxr-xr-x 2 lx lx 4096 Mar 26 10:28 Downloads/ drwx------ 4 lx lx 4096 Apr 1 23:25 .gconf/ drwx------ 2 lx lx 4096 Apr 2 11:36 .gconfd/ drwx------ 6 lx lx 4096 Apr 1 23:49 .gnome2/ drwx------ 2 lx lx 4096 Apr 1 23:49 .gnome2_private/ drwx------ 3 lx lx 4096 Mar 26 10:28 .gnupg/ drwxrwxr-x 2 lx lx 4096 Apr 1 23:25 .gstreamer-0.10/ -rw-rw-r-- 1 lx lx 122 Apr 1 23:25 .gtk-bookmarks drwx------ 2 lx lx 4096 Mar 26 10:29 .gvfs/ -rw------- 1 lx lx 660 Apr 1 23:25 .ICEauthority drwxrwxr-x 2 lx lx 4096 Mar 26 10:30 .icons/ drwx------ 3 lx lx 4096 Mar 26 10:28 .kde4/ drwxr-xr-x 3 lx lx 4096 Mar 26 10:30 .local/ -rw-rw-r-- 1 lx lx 0 Mar 26 10:28 .mdk-menu-migrated drwx------ 4 lx lx 4096 Apr 1 23:49 .mozilla/ drwxr-xr-x 2 lx lx 4096 Mar 26 10:28 Music/ drwxr-xr-x 2 lx lx 4096 Mar 26 10:30 .nautilus/ drwxr-xr-x 2 lx lx 4096 Mar 26 10:28 Pictures/ drwx------ 2 lx lx 4096 Apr 1 23:25 .pulse/ -rw------- 1 lx lx 256 Mar 26 10:30 .pulse-cookie drwxr-xr-x 2 lx lx 4096 Mar 26 10:28 Templates/ drwxrwxr-x 2 lx lx 4096 Mar 26 10:30 .themes/ drwx------ 4 lx lx 4096 Mar 26 10:30 .thumbnails/ drwx------ 2 lx lx 4096 Jan 11 12:42 tmp/ drwxr-xr-x 2 lx lx 4096 Mar 26 10:28 Videos/ -rw------- 1 lx lx 5513 Apr 2 11:54 .xsession-errors -rw------- 1 lx lx 1160 Mar 26 12:50 .xsession-errors.old
Bug still present.
CC: (none) => thierry.vignaud
What's about 750? So at first nobody can change into $HOME. If you want to change this you can change your usergroup for example to users. So everybody can see nearly everything but things which are relevant to security are still protected by their own rights. That would bee the middle between Installer and Userdrake.
stil valid for Mga2Alpha1, assigning
CC: (none) => marja11Assignee: bugsquad => thierry.vignaud
Pinging, because nothing has happened with this report for more than 3 months, it still has the status NEW or REOPENED.
CC: (none) => dglent
Hi, This bug was filed against cauldron, but we do not have cauldron at the moment. Please report whether this bug is still valid for Mageia 2. Thanks :) Cheers, marja
Keywords: (none) => NEEDINFO
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as OLD.
Status: NEW => RESOLVEDResolution: (none) => OLD
Sorry, I hadn't checked what this bug is about, but bug 1259 made me aware. Nothing changed, the home directory for the user created during install still has drwxr-xr-x
Keywords: NEEDINFO => (none)Status: RESOLVED => REOPENEDResolution: OLD => (none)Whiteboard: (none) => (Mga2)
Summary: Installer and userdrake give different permissions to user home directories => Installer gives 755 permissions to user home directories
Please look at the bottom of this mail to see whether you're the assignee of this bug, if you don't already know whether you are. If you're the assignee: We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead. If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard. Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why. Thanks :) **************************** @ the reporter and persons in the cc of this bug: If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us. @ the reporter of this bug If you didn't reply yet to a request for more information, please do so within two weeks from now. Thanks all :-D
@ ennael Mrs B suggested there was maybe a good reason to keep this like it is, and that you might be able to tell, so cc'ing you and her :-D
CC: (none) => eeeemail, ennael1
Whiteboard: (Mga2) => (Mga2) 3alpha2
Whiteboard: (Mga2) 3alpha2 => 3alpha2 (Mga2)
valid 3beta1
Whiteboard: 3alpha2 (Mga2) => 3alpha2 3beta1 (Mga2)
valid 3beta2, first set of isos IMHO, this should already have been a release blocker long ago
Priority: Normal => release_blockerWhiteboard: 3alpha2 3beta1 (Mga2) => 3alpha2 3beta1 3beta2
TBH, the reason that I think it should be a release blocker, is that I think there are more people like me. This is something one doesn't expect of a Linux distro at all. So even when you hear about this bug, you forget about it. I've let people use my laptop (even at events), while /home/marja/ was still world readable :(
I remarked in my system (Mageia2) that if i create a file as root, the user is able to delete it. It is normal ? or, it is related to this bug?
(In reply to comment #21) > I remarked in my system (Mageia2) that if i create a file as root, the user is > able to delete it. It is normal ? or, it is related to this bug? I changed the permissions of /home/marja/ to 700 After that: [root@Denkblok2 marja]# touch dglenttest [root@Denkblok2 marja]# ls -l dglenttest -rw-r--r-- 1 root root 0 janv. 18 11:56 dglenttest [root@Denkblok2 marja]# exit [marja@Denkblok2 home]$ cd ~ [marja@Denkblok2 ~]$ rm -fv dglenttest « dglenttest » supprimé [marja@Denkblok2 ~]$ ls -l dglenttest ls: impossible d'accéder à dglenttest: Aucun fichier ou dossier de ce type [marja@Denkblok2 ~]$ So it can still be removed. However, which files, apart from ../, could root want to own in any user's home directory?
I would say that the default should be 750. No access to others by default. If someone wants to give access (s)he can do so and it's his/her responsibility then. Currently we are not protecting the user. (In reply to comment #21) > I remarked in my system (Mageia2) that if i create a file as root, the user is > able to delete it. It is normal ? or, it is related to this bug? AFAIK you can delete files/folders if you have writing permission on the parent folder. But you can't change their permissions nor edit content.
CC: (none) => sander.lepik
nothing happening on this bug since januari... should we just close this one as WONTFIX? or at least dropping release_critical status?
CC: (none) => alien
It can't be that hard to fix. Or is it, Thierry? Definitely not a WONTFIX..
This is not an installer issues. Permissions came from UMASK value in /etc/login.defs from shadow-utils
Component: Installer => RPM PackagesSource RPM: drakxtools => shadow-utils
is this related to security level at install time? if so, then maybe this _is_ a wontfix, unless any of you can agree that 750 is a better idea for the lowest security level... the point is, there are much more important bugs... we'd better just decide on what to do and get rid of this bug.
Actually the bug is in userdrake which forces 0700 whereas adduser & libuser reley on /etc/login.defs values. And there's nothing urgent in this bug report
Priority: release_blocker => NormalSource RPM: shadow-utils => userdrake2Severity: major => normal
(In reply to Thierry Vignaud from comment #28) > Actually the bug is in userdrake which forces 0700 whereas adduser & libuser > reley on /etc/login.defs values. > And there's nothing urgent in this bug report Maybe not for developers, who are aware of things most users aren't. For avarage end-users it'll be different. Few parents who install Mageia and adds their kids after reboot will, when seeing their kids' home directories are protected as expected, imagine the kids can read the documents of the parents To me it even happened that my .ssh/id_rsa became been world readable once after I had copied it from another install into a world-readable /home/marje/ while having forgotten about this bug. I suppose developers will copy on the command line while preserving the rights of whatever they copy. However, most users won't even know that is possible. IMHO, if it isn't fixed, it should be documented. cc'ing docteam
CC: (none) => doc-bugs
I think there is won't harm anyone if it will be changed but the actual setting confuse many people. â And it's simple to chnage it. So why not changing this behavior?
IMHO, the problem is not about the default permissions of $HOME, the problem is maybe more about the default umask of 0022. Maybe 0027 would be better as a default umask. Why do I say this? Let's say you do want to share *some* directories with users other than members of your primary group (whether it be the ~/public_html for the apache user, or some files you copied for a different team), then you will need 711 minimum on $HOME, and if umask was 0022, then all your files (created while umask 0022 was in effect, that weren't changed) would be world-readable (except for security-concious apps in the event the user saw the warnings). With a default umask of 0027, the permissions of $HOME are not as relevant (751 would maybe be a good default).
CC: (none) => bgmilne
You don't need 711 you can use 710 and add www-data to the group of the home-holder. But I think the solution with default umask 0027 is nice. (Much nicer than changing only the permitions of $HOME.)
CC: (none) => pierre-malo.denielou
Ok. I think we should change the default umask in shadow-utils to 0027. This will provide a coherent setup. We can fix userdrake to actually use /etc/logins.def afterwards. Any objection?
it's fine for me, until something better comes along
(In reply to Malo Deniélou from comment #33) > Ok. I think we should change the default umask in shadow-utils to 0027. This > will provide a coherent setup. > We can fix userdrake to actually use /etc/logins.def afterwards. > Thanks, Malo :-D Would that mean you can close bug 1259 [Set default umask to 0027 (Was: User's homedir world readable)] when you changed the default umask in shadow-utils? In other words, doesn't Ahmad's comment https://bugs.mageia.org/show_bug.cgi?id=1259#c1 apply anymore in Mageia 3?
Restoring initial summary
Summary: Installer gives 755 permissions to user home directories => Installer and userdrake give different permissions to home directories
Trowing in my 2 öre; regardless of fixing default umask, it would look much better if homes always have the same default rights. And there i vote for 750.
CC: (none) => fri
Well, We need to do something here. If (reported in Bug #10792) a users adds a new user through userdrake and loggin into this account, there are a lot fo problems, including a missing taskbar. This is valid for mga3 too.
Priority: Normal => HighCC: (none) => thomasSeverity: normal => critical
IMHO this bug became pretty convoluted. This bug is essentially about userdrake (actually libuser) not respecting the default umask from /etc/login.defs. This is the bug at hand that should be fixed. Thierry even reported this upstream https://bugzilla.redhat.com/show_bug.cgi?id=957283 and as an interim fix seems we can only change the hardcoded value userdrake in line 177 in http://svnweb.mageia.org/soft/userdrake2/trunk/USER/USER.xs?revision=7992&view=markup because libuser ignores the umask settings, and a replacement library is currently not in sight. The discussion about default permissions is something totally different and does not belong in this bug.
CC: (none) => doktor5000
See Also: (none) => https://bugzilla.redhat.com/show_bug.cgi?id=957283
make that > the hardcoded value in line 117 in http://svnweb.mageia.org/soft/userdrake2/trunk/USER/USER.xs?revision=7992&view=markup
*** Bug 13718 has been marked as a duplicate of this bug. ***
CC: (none) => kalagani
CC: dglent => (none)
i had two user accounts, on mag4. a fresh install of mag5, not an update, with default settings everytime, and a new user account has been made, with the same root passphrase. now, logged in the new user account , i have free access to the three accounts.
CC: (none) => yutz--a
(In reply to oui cestcela from comment #42) > i had two user accounts, on mag4. > a fresh install of mag5, not an update, with default settings everytime, and > a new user account has been made, with the same root passphrase. > now, logged in the new user account , i have free access to the three > accounts. I do not understand how you make your account: at installation or after? On my fresh Mageia5 install rights are differents between my first patrick account made at install and my second zinvite account made after install with CCM! ll total 24 drwx------ 2 root root 16384 août 6 22:02 lost+found/ drwxr-xr-x 27 patrick patrick 4096 sept. 7 22:18 patrick/ drwx------ 4 zinvite zinvite 4096 sept. 7 22:19 zinvite/
(In reply to oui cestcela from comment #42) > i had two user accounts, on mag4. > a fresh install of mag5, not an update, with default settings everytime, and > a new user account has been made, with the same root passphrase. > now, logged in the new user account , i have free access to the three > accounts. Hello, Users account security policy is this one: - Any user you add while installing Mageia, will have a world readable (but write protected) home directory. - Any user you add in MCC -> System -> Manage users on system will have a home directory that is both read and write protected. cheers Lebarhon
CC: (none) => lebarhon
I think, this is what it should be, also when installing it.(In reply to André DESMOTTES from comment #44) > (In reply to oui cestcela from comment #42) > > i had two user accounts, on mag4. > > a fresh install of mag5, not an update, with default settings everytime, and > > a new user account has been made, with the same root passphrase. > > now, logged in the new user account , i have free access to the three > > accounts. > > Hello, > Users account security policy is this one: > - Any user you add while installing Mageia, will have a world readable (but > write protected) home directory. > - Any user you add in MCC -> System -> Manage users on system will have a > home directory that is both read and write protected. I think, this is what it should be, also when installing it. > > cheers > Lebarhon
Can someone summarize this bug and tell if it's still valid and what the possible solutions are?
*** Bug 1259 has been marked as a duplicate of this bug. ***
CC: (none) => fhimpe
do we agree to change the default umask in shadow-utils to 0027 ? now we have 022 (like Ubuntu) , Fedora have 077
CC: (none) => makowski.mageia
(In reply to Philippe Makowski from comment #48) > do we agree to change the default umask in shadow-utils to 0027 ? > > now we have 022 (like Ubuntu) , Fedora have 077 0027 is *much* better than what we have now, and I don't think anyone proposed a different umask here. On the contrary: (In reply to Buchan Milne from comment #31) > IMHO, the problem is not about the default permissions of $HOME, the problem > is maybe more about the default umask of 0022. Maybe 0027 would be better as > a default umask. (In reply to Malo Deniélou from comment #33) > Ok. I think we should change the default umask in shadow-utils to 0027. This > will provide a coherent setup. > We can fix userdrake to actually use /etc/logins.def afterwards. > > Any objection? (In reply to AL13N from comment #34) > it's fine for me, until something better comes along However, at least tv & doktor5000 argued this bug is not about default umask values, but about useradd and luseradd behaving differently https://bugzilla.redhat.com/show_bug.cgi?id=957283 So having umask 0027 still wouldn't make installer (which depends on libuser and on http://gitweb.mageia.org/software/userdrake/tree/USER/USER.xs#n117 ) use it [root@localhost home]# useradd useradd [root@localhost home]# luseradd luseradd [root@localhost home]# ls -al| grep useradd drwx------ 4 luseradd luseradd 4096 okt 29 14:56 luseradd/ drwxr-xr-x 4 useradd useradd 4096 nov 13 16:07 useradd/ [root@localhost home]# or, right after adding users with userdrake and adduserdrake: [root@localhost home]# ls -al | grep userdrake drwxr-xr-x 4 adduserdrake adduserdrake 4096 nov 13 16:13 adduserdrake/ drwx------ 4 userdrake userdrake 4096 okt 29 14:56 userdrake/ [root@localhost home]# So, Philip, _yes_, please go ahead and change the default umask to 0027, but don't close this report, yet ;-)
(In reply to Philippe Makowski from comment #48) > do we agree to change the default umask in shadow-utils to 0027 ? > > now we have 022 (like Ubuntu) , Fedora have 077 Nobody objected. Did you commit the fix and push yet?
(In reply to Samuel Verschelde from comment #50) > (In reply to Philippe Makowski from comment #48) > > do we agree to change the default umask in shadow-utils to 0027 ? > > > > now we have 022 (like Ubuntu) , Fedora havenope 077 > > Nobody objected. > > Did you commit the fix and push yet? nope, because of https://bugs.mageia.org/show_bug.cgi?id=18984
Keywords: (none) => PATCHDepends on: (none) => 18984
shadow-utils updates were done for both cauldron and mga5 which include the default mask change to 0027 discussed here.
CC: (none) => mrambo
Created attachment 9066 [details] correctly set permissions on the home directory, v1 userdrake now follows umask, and falls back to 700 if /etc/login.defs cannot be found.
Status: REOPENED => ASSIGNEDAssignee: thierry.vignaud => LpSolit
sound good for me. To start with good use, can you document new function, in a perl way ? so we will be able to start to do it for other function and extract our documentation :)
CC: (none) => mageia
Created attachment 9067 [details] correctly set permissions on the home directory, v1.1 Now with POD. Type: perldoc userdrake to see the documentation in a formatted way.
Attachment 9066 is obsolete: 0 => 1
Created attachment 9068 [details] correctly set permissions on the home directory, v2 I had to fix conflicts with Angelo's patch from bug 20436. I refactored his code to use the new get_params() function included in this patch.
Attachment 9067 is obsolete: 0 => 1
commit 53b16d4a8286033edd1a9532a88a5bb2ef35b8ae Author: Frédéric Buclin <LpSolit@...> Date: Sat Mar 11 17:16:08 2017 +0100 Correctly set permissions on the home directory when creating a new user (mga#618) --- Commit Link: http://gitweb.mageia.org/software/userdrake/commit/?id=53b16d4a8286033edd1a9532a88a5bb2ef35b8ae
fixed
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXEDTarget Milestone: --- => Mageia 6
Fixed package pushed to cauldron, userdrake-2.15-1.mga6.
Source RPM: userdrake2 => userdrake
Hello, We have today a warning in our documentation: "Any users added while installing Mageia, will have a home directory that is both read and write protected (umask=0027) You can add any extra needed users in the Configuration - Summary step during the install. Choose User management. The access permissions can also be changed after the install." Do you think this warning is still adequate?
CC: (none) => yves.brungard_mageia
Hello, It shouldn't be a "warning" but a "note" because it is a feature that is good to know.