Home permissions too open

[DanielT]

Binary package hint: debian-installer

On a fresh dapper install i noticed that the file permissons for the home directory for the user created by the installer is set to 755, giving read access to everyone on the system.

Surely this is a bad idea? If your set on the idea can we atleast have a option during the boot proccess?

Also new files that are created via the console ('touch' etc.) are done so with '644' permissons, is there anything that can be done here? nautlius seems to create files at '600', which is a better setting.

[Colin Watson (cjwatson)]

This is done by adduser, actually, not by any installer component. In expert mode I believe you should get a prompt about it.

However, I do maintain that the default is correct. On most multi-user systems, there is some level of cooperation (if not trust) among the users - they'll be members of the same family, or friends, or co-workers, or whatever - and it is useful for them to be able to share files reasonably conveniently (e-mail is an awful solution to this). It's easier to create a private directory for the things you don't want to be public than it is to figure out how to open up your home directory so that just a few things can be read. (I use quite a lot of multi-user Unix systems on a regular basis, both at work and among my family and friends, and it's far more common for me to want things accessible to other users than it is for me to want them to be inaccessible.)

There are certainly systems where this is not appropriate (large multi-user systems where you pay for a shell account), but they are generally run by competent system administrators who know how to lock things down.

For permissions on new files created by touch et al, set 'umask 077' in your shell startup files if you want them to be mode 600 by default.

[Colin Watson (cjwatson)]

By the way, to change the default for new users on an existing system, change DIR_MODE in /etc/adduser.conf.

[kko (kko)]

Thank you for the very clear explanation of Ubuntu's policy on the home directory permissions issue.

A special thanks for the DIR_MODE -tip - every day you learn something new. ;-)

[unggnu (unggnu)]

Why not ask in the installer while the password and user name is set if the directory should be readable or not? One line with a checkbox and an explanation would be enough. After installation the gnome user manager should ask the same question if a new user is added. Everyone who uses console tools will know what to do I guess so there is no priority for it.
I guess the only point of discussion is the default configuration. For me there is no problem if it is enabled per default when there is a configuration line in the installer/user configuration.

[unggnu (unggnu)]

Another interesting point is that Ubuntu has a guest session which works great but interestingly the user from which the guest session is initiated returns with a locked screen which seems to be a security feature. But it is still possible for the guest to access most of the data in the home user directory because of this bug except of some ssh and gpg things.

I really think that it is better to just create a shared folder which is shown on the desktop and places instead of opening the home directory wide. This also wouldn't need installer interaction and should be easily understandable because Windows practices this at least since XP.

[unggnu (unggnu)]

Maybe it wasn't clear.
A non expert Ubuntu user has tested the guest mode and find out that his screen is locked afterwards and he could come to the impression that this is safe. Especially since he heart Linux is much more secure than Windows and so on.
So if he has to leave he just switch to guest mode to let a friend, sister, flat share or whoever use his computer in his absence thinking that his personal stuff is safe.
So with this default configuration everything depends on the permission setting of each app. Firefox seems to set restrictive permissions but many other apps not. And even if the settings are safe the standard Ubuntu directories for pictures, documents and so on aren't.

If there really is a need for sharing files between users a standard shared folder would work around the problem.
Btw. every experienced user knows how to change the home directory to make it less restrictive so it wouldn't bother them but it would be more secure for every one.

[aysiu (ubuntubugzilla-psychocats)]

"On most multi-user systems, there is some level of cooperation (if not trust) among the users - they'll be members of the same family, or friends, or co-workers, or whatever"

I don't think you can rightly make that assumption. Even if it is true in most cases, it is better for people to opt in to sharing files than to have to opt out of it.

"and it is useful for them to be able to share files reasonably conveniently (e-mail is an awful solution to this). It's easier to create a private directory for the things you don't want to be public than it is to figure out how to open up your home directory so that just a few things can be read."

How about just creating a shared directory, then?

644 is pretty useless for sharing (for example, if I want to share a music collection with my whole family, they cannot right to my music collection, and I cannot write to theirs, so we would have to do a lot of duplicate checking or have only one person add songs, which would be ridiculously cumbersome).

/home/username would be 600 by default

/home/shared would be 660 or 666 by default

What's wrong with that scenario?

[Colin Watson (cjwatson)]

I'm afraid we'll have to agree to disagree on this one. I firmly believe
that if people have to opt in to being able to share files with each
other then they simply won't do it, or will use absurd,
expensive-for-the-Internet workarounds (like e-mailing files to each
other). Most people don't lock their desks up by default either, only if
they have a clear reason to do so. The knob is there for people to tweak
and I honestly am not interested in discussing it beyond that at the
level of the installer. I recommend opening a separate bug to make it
easier to configure this sort of thing at the desktop level.

Somebody should probably also open a separate bug to have the apparmor
configuration for the guest session a bit stricter.

[unggnu (unggnu)]

A simple shared folder with an link on every user desktop would make everyone happy but ...

[Colin Watson (cjwatson)]

On Sat, Aug 01, 2009 at 07:11:04AM -0000, unggnu wrote:
> A simple shared folder with an link on every user desktop would make
> everyone happy but ...

... but that's a desktop decision, not something adduser should be
doing. (And it would make me unhappy personally because it would be
noise on the desktop, which is otherwise clean by default; I believe
that that is an explicit Ubuntu desktop design decision.)

[unggnu (unggnu)]

No problem at all since it could be stored under Places which makes more sense anyway.

If there is a shared folder there is no need to keep the permissions as open anymore imho.

[flaccid (chris-xhost)]

Whatever solution is decided upon, as long as home dirs via adduser etc. are NOT world readable then its ok.
We should also be educating users instead of getting them into bad habits such as sharing home directories - you won't see any decent administrator set this up on a LAN's LDAP or similar.

The basic concept is this: A user has a password, which suggests that a user's resources are protected by this password. Currently this is not the case due to the wrong mentality and current policy in Ubuntu.

I've pointed out to dozens of users that 'hey did you know anyone can read your home folder?'. They are inheritantly shocked when they check my accusation, and a lot reply with 'Gee, Windows is even more secure than this'.

So whats next? IMHO, we should be looking at how other operating systems current share files between local users - check OS X, MS Windows, other distros/*nix etc. Personally I think one of the management options is the DE to provide a tool to share a folder - and hey lets not forget that in Gnome and KDE users can already click a folder and goto its permission's and easily change who can read it. Ideally I think that that every user should know the basics to UNIX/Posix FS permissions also.

[Carroarmato0 (carroarmato0)]

How about locking down users folders to them selves and use Samba to deal with the shares? User's have a graphical tool anyway to easily configure the sharing options of Samba. Maybe this could be a valid agreement? Though this would involve either adding Samba on the installation Cd or postpone installation after the system has been installed or on request of the user.

[flaccid (chris-xhost)]

@Carroarmato0
Samba server in Ubuntu is not installed or enabled by default. This is also networking sharing, not simple local sharing via UNIX perms. Although Ubuntu lacks a real implementation of Samba that is a transparent config to the user, a network sharing filesystem is not really applicable here. A frontend that allows a user to share a folder in their homedir that is initially forbidden, is really what we need; its already there in the DEs as I mentioned, but not transparent to the user.

It is the responsibility of the DE and/or distro to provide a facility for a newbie-level user to easily allow sharing of a private folder.

[David Henningsson (diwic)]

Actually in my home folder in my default Karmic installation, there is a folder named "Publikt" (that'd probably be "public" or "shared" in English), tricking me into believing that everything else is not public - if it was, why would there be a "Publikt" folder in my home directory?

Since it seems to be hard to reach consensus here, could we consider a checkbox in the default installation, something like "Make your home directory readable to all users", somewhere around "encrypt your home directory"?

[Olli (olli-kinnunen)]

Incredible !
This bug thread has existed almost 4 years now (with some side threads) and there is no decision that the described behaviour of /home is absolutely not acceptable.

For a "normal" user, everything which is behind my own password, is absolutely mine and only mine.

Somebody says (in some thread) that this is wellknown and accepted behaviour. It may be wellknown for you as "linux-pros", but it is not known and accepted by the major share of the users. Users who are new to linux, to whom every "old" linux tutor says that linux is absolutely safe to use.

An OS is not safe if someone else can (so easily) read my diary, my last will draft, my financial situation etc. etc., anything which is absolutely mine only.

My suggestion is that this behaviour is closed immediately in all existing versions, furthermore instructions are distributed on the Ubuntu web pages how to prevent the usage of the BUG.

The wiki link:
https://wiki.ubuntu.com/DebuggingSecurity#Permissive%20Home%20Directory%20Permissions
is not enough, people do not read thousands of pages just for fun.

The content of that page raises a dejavue-feeling:

"No, it is not a bug, it is a feature"

[Mark Shuttleworth (sabdfl)]

Olli, I appreciate that you would like the matter to be handled
differently, but a decision has been taken. Every decision can be
changed, but it will only be changed if the facts or circumstances or
arguments changed. Showing up, talking loudly, but adding nothing other
than a strong statement of your preferences is not going to change it.

Mark

[Olli (olli-kinnunen)]

Mark,

"a decision" ?

I am sorry but I cannot see any ?

And that is why I wanted to raise the flag.

[CalderCoalson (ccoal)]

First, I was quite surprised to see a response from you yourself, Mark, and
appreciate your direct involvement. Second, while Olli's response was
rather incensed, it is representative of many people's reactions when they
discover this feature. I'm sure there are very good reasons this choice
persists, but it helps people to know what they are. If you could briefly
elaborate on the "facts or circumstances or arguments" that have lead to
this decision people would no longer feel they are
being unreasonably ignored, and thereby reduce the need for electronic
voice-raising.

On a final note, it's worth noting that this does qualify as a "security
bug" by the definition on the wiki:
"accessing information that should be blocked. For example, a user on the
system being able to view or modify private files of another user. ("Loss of
Privacy")"

On Thu, Mar 11, 2010 at 10:07 AM, Mark Shuttleworth <email address hidden>
wrote:
>
> Olli, I appreciate that you would like the matter to be handled
> differently, but a decision has been taken. Every decision can be
> changed, but it will only be changed if the facts or circumstances or
> arguments changed. Showing up, talking loudly, but adding nothing other
> than a strong statement of your preferences is not going to change it.
>
> Mark
>
> --
> Home permissions too open
> https://bugs.launchpad.net/bugs/48734
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “adduser” package in Ubuntu: Invalid
>
> Bug description:
> Binary package hint: debian-installer
>
> On a fresh dapper install i noticed that the file permissons for the home
directory for the user created by the installer is set to 755, giving read
access to everyone on the system.
>
> Surely this is a bad idea? If your set on the idea can we atleast have a
option during the boot proccess?
>
> Also new files that are created via the console ('touch' etc.) are done so
with '644' permissons, is there anything that can be done here? nautlius
seems to create files at '600', which is a better setting.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734/+subscribe

[Colin Watson (cjwatson)]

I believe that the previous comments from me on this bug were quite well-thought-out and explanatory. I certainly made an effort to give a clear explanation of why I believe this to be the correct default rather than just saying "no", and I also noted ways in which I think this could be improved at the desktop UI level.

[Mark Shuttleworth (sabdfl)]

The majority of users of Ubuntu systems either have exclusive use of the
machine (personal laptop) or are sharing with friends and relatives. We
assume that the people who share the machine are either trusted, or in a
position to hack the machine (boot from USB!) trivially. As a result,
there is little to no benefit from the permissions you propose.

Now, in a more complex environment, like a university machine with many
users, people do not have access to the hardware and can't easily root
the box, but they also have the sysadmin skills to change the default
permission.

Ergo, we stick with the permission as they stand today.

Mark

[flaccid (chris-xhost)]

@Mark Shuttleworth

I don't know where to start with your flaws, but I'll at least flag a few + relevant points.

1. A majority != all
2. The wiki confirms that this is a security bug
3. People store their mail in the home directory (this is only 1 example). You can then own the user or get the information you need etc. Identity theft is huge and this is only one of the consequences
4. Linux for human beings? We like privacy. Sharing with friends or relatives.. Believe it or not, most friends and relatives like to keep their personal information private, I'm sure you do too
5. You say the word 'assume'. Why would you ever assume trust? Security Engineers are paid to prevent such assumptions
6. Sure you can circumvent via USB boot, but in Ubuntu you can use an encrypted FS or encrypt folders to negate this if you want to
7. Ubuntu is being used in Universities, schools, organisations etc. Wasn't this an objective of Ubuntu - to gain market share/use/awareness in any environment? Are you really ignorant to think that Ubuntu is only being used at home?
8. Real unix/posix operating systems don't make home dirs public. A lot of admins won't even think about checking the perms as a result. We get totally shocked when we first find this out, and obviously a lot have already been bitten.

One only has to look at competitors such as OS X to see that sharing features/frontends have been placed in the Desktop Environment to allow users to easily share files within sub-folders of their home.
You may be suprised, but I have never heard anyone complain that this is hard for an inexperience user to do.

[CalderCoalson (ccoal)]

Without getting all worked up here, flaccid does raise one very good point.
 The Mac OS X system works beautifully; that is making everything locked by
default except for a folder explicitly labeled "Public" containing a "Drop
Box" for file transfer to the user. This approach respects both
perspectives, making it extremely easy to share what you want while still
respecting privacy and security by default.

On Thu, Mar 11, 2010 at 9:44 PM, flaccid <email address hidden> wrote:

> @Mark Shuttleworth
>
> I don't know where to start with your flaws, but I'll at least flag a
> few + relevant points.
>
> 1. A majority != all
> 2. The wiki confirms that this is a security bug
> 3. People store their mail in the home directory (this is only 1 example).
> You can then own the user or get the information you need etc. Identity
> theft is huge and this is only one of the consequences
> 4. Linux for human beings? We like privacy. Sharing with friends or
> relatives.. Believe it or not, most friends and relatives like to keep their
> personal information private, I'm sure you do too
> 5. You say the word 'assume'. Why would you ever assume trust? Security
> Engineers are paid to prevent such assumptions
> 6. Sure you can circumvent via USB boot, but in Ubuntu you can use an
> encrypted FS or encrypt folders to negate this if you want to
> 7. Ubuntu is being used in Universities, schools, organisations etc. Wasn't
> this an objective of Ubuntu - to gain market share/use/awareness in any
> environment? Are you really ignorant to think that Ubuntu is only being used
> at home?
> 8. Real unix/posix operating systems don't make home dirs public. A lot of
> admins won't even think about checking the perms as a result. We get totally
> shocked when we first find this out, and obviously a lot have already been
> bitten.
>
> One only has to look at competitors such as OS X to see that sharing
> features/frontends have been placed in the Desktop Environment to allow
> users to easily share files within sub-folders of their home.
> You may be suprised, but I have never heard anyone complain that this is
> hard for an inexperience user to do.
>
> --
> Home permissions too open
> https://bugs.launchpad.net/bugs/48734
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “adduser” package in Ubuntu: Invalid
>
> Bug description:
> Binary package hint: debian-installer
>
> On a fresh dapper install i noticed that the file permissons for the home
> directory for the user created by the installer is set to 755, giving read
> access to everyone on the system.
>
> Surely this is a bad idea? If your set on the idea can we atleast have a
> option during the boot proccess?
>
> Also new files that are created via the console ('touch' etc.) are done so
> with '644' permissons, is there anything that can be done here? nautlius
> seems to create files at '600', which is a better setting.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734/+subscribe
>

[Marc Deslauriers (mdeslaur)]

I think you guys should take a look at the permissions on your OS X home directory, you'll be surprised :)

Our security team FAQ has instructions on changing the default behavior for home directories:
https://wiki.ubuntu.com/SecurityTeam/Policies#Permissive%20Home%20Directory%20Access

That being said, applications should already be storing private data in your home directory with restrictive permissions. If you spot an application that stores private data such as email or browser history with inadequate permissions, please file bugs.

Our official solution to keeping user data private is to use home directory encryption by checking the "Require my password to log in and to decrypt my home folder" option during installation.

[unggnu (unggnu)]

I also think that one public directory like Windows or maybe even MacOsX have per default would be the best compromise. I mean this could be created in the home directory and a link added to every new user desktop like in case of the example folder.
With this sharing is even easier than with the current situation and others get their privacy.

Of course changing permissions is easy to evade through booting a live environment but we are not talking about professionals. I mean basically every security system could be breached but the effort and expectation is important I think.

For example afaik if a user logs in with an encrypted home directory it could be accessed from everyone as long as the user is logged in which is possible through user switching. In this case the directory permission would also help to protect the files.
Even if it would be not the case someone could boot a live environment and install a keylogger or similar.

[CalderCoalson (ccoal)]

Encryption also adds significant overhead to file read / writes which people
on slower computers can't really afford. As for booting from a USB drive,
there's a huge difference between a family member (if we're assuming that
usage scenario) doing a computer wide search and turning up a private email
or diary entry or something, and someone maliciously booting off a USB-drive
expressly to gain access to your files. Finally, if you're already offering
a psuedo-fix option during the installation process, why not add a real
check box that says
"Allow all users view the contents of my home directory."

I think you'd be surprised by how many people uncheck that.

[Marc Deslauriers (mdeslaur)]

If you restrict permissions on the home directory, it isn't possible to have a folder _inside_ that is accessible by other users. This is the way Unix permissions work. This is why the home folder is readable by other users by default on OS X, so the "Shared" folder is accessible.

[CalderCoalson (ccoal)]

I think that's what we're agreeing Ubuntu should do as well, with two
changes to make it more Mac OS X-like. First, the default folders (with the
exception of Public) should be locked to all other users. Second, any new
folders that get created should also be locked to all other users. Mac OS X
doesn't even need the second restriction because it stores the mad
proliferation of application data in ~/Library rather than ~/.appnamehere,
but I can't think of any instance in which one user needs to access another
users's application data.

[Marc Deslauriers (mdeslaur)]

The ~/.appnamehere folders should already have restrictive permissions set by the applications. For example, ~/.mozilla is 700. If you use an application that doesn't set sane permissions for private data, please file a bug.

Any new folder you create in your home directory in OS X is automatically shared to other people, as the default umask on OS X is the same as Ubuntu.

What other folders do you want restricted by default? Documents, Music, Pictures, Videos? It seems to me those _are_ the folders you would want to share...

Should we create a "Private" directory by default with restrictive permissions?

[JeSTeR7 (cblocker)]

Creating a "Private Directory" by default would at least hint to the user that the other directories are not, in fact, private.

[CalderCoalson (ccoal)]

That's a start, but a Public would make so much more sense. Then when you
want to share something you do that, but you don't have to separate the
organization of your documents and other personal files by whether they're
"private" or not. Would it really be too hard to add a checkbox for this so
people could choose for themselves? If you collected the data on who choses
what, I would be willing to bet even if it weren't default at least 50% of
people would choose to protect their home directories.

As an aside, the ~/.appname being private is by no means standard or
default. In fact, most of them are public. A short list:
.bluej
.codeblocks
.config
.dia
.evolution
.fontconfig
.freemind
.gimp
.gstreamer
.gtk-bookmarks
.hardinfo
.icons
.java
.kde
.nautilus
.openoffice.org
.subversion
.svnqt
.texmf-var
.themes
.update-manager-core
.wapi
.wine
And that's just on my system...

On a semi-related note, is there any actual reason why Linux defaults to
cluttering home directories with invisible files? Mac OS X's system of
storing everything in a Library folder again seems far more intelligent, as
we could avoid this whole problem by locking the ~/Library folder as Mac OS
X does.

[unggnu (unggnu)]

@Marc Deslauriers
I meant creating the public folder in the global home directory "/home" not the user home directory.

And if a link on the desktop is against the gui guidelines just add one under "Places" or in the user home directory.

[David Henningsson (diwic)]

@CalderCoalson: Long story short, cluttering home directories with invisible files is part of the FHS standard. There is also a freedesktop standard that dictates that configuration should be put in a subdirectory under ~/.config/. My personal preference is for the latter.
And the .config directory is 755 (i e not locked up for other users)...

As a side note, does anybody know how other distributions deal with this issue? My guess is that almost everyone else locks it up by default, but I don't know for sure. And that in turn leads to upstreams assuming that, and therefore not caring about what permissions they put on their invisible files.

[Mark Knowles (markknowles)]

This is a shocker.

This is yet another example of Ubuntu not taking security seriously. This is not a problem on RedHat or Fedora.

And this issue exists on the server edition as well! Reading each other's files by default is _not_ cool. I can't believe how long I've been running with such an insecure configuration.

[flaccid (chris-xhost)]

After some of the comments I did look at some other *nix OS and distros and observed that quite a few do have open home directories too by default. There are however quite a few that apply protection.

It is just a question of which category Ubuntu wants to be in. At this point, it looks like the former which is a shame.

Microsoft Windows even protects user's files by default. IMHO, if we want to remain mediocre and not add protection, then we could at least provide an informative dialog in the installer or create user GUI to advise that the created user has a world readable home.

No opt-in to 'sharing' as its been called is plain ridiculous. With servers, sysadmins are responsible in this area, but this is Ubuntu - linux for human beings, on the desktop.

[emarkay (mrk)]

Wow even the SABDFL chimed in, but...

Correct me if I am wrong, as I have not spent hours studying this.

My "home" directory is accessible to me, as I am logged in.
It is NOT accessible to anyone else logged into my PC with their password.
It is NOT accessible by anyone on a network, or online (a large network).

If the above is not true, this will open up an unfun can of worms for the Diggers and Redditers, as well as a bunch of other places.

Clarification on this, please, ASAP.

[flaccid (chris-xhost)]

@emarkay
Thats explained above if you read the history.
The simple answer is yes, any system user can read anything in /home/*

I did notice that what people are saying is correct... it is like this with many other distros and OS.
But, imho, this shouldn't mean that Ubuntu does the same.

Do we want to be a leader or a follower?
Ubuntu - Linux for human beings.
Well, humans like privacy.

[Olaf van der Spek (olafvdspek)]

@Colin, Mark: What about Principle of least privilege? Safe-by-default?
Why does user www-data (for example) have access to my files?

The defaults provide access to way more than other humans. You might at least want to use ACLs to limit it to other humans by default.

It should be clear by now that some users expect a private home dir. Why not provide an easy way to switch from private to public?

[Olaf van der Spek (olafvdspek)]

Somebody?
Implementing a public dir for easy sharing can IMO be easily done with defaulting to a world readable home dir.

[Olaf van der Spek (olafvdspek)]

Sorry, that should read: "without defaulting to a world readable home dir."

[Olaf van der Spek (olafvdspek)]

> status: New → Opinion

That's silly, could someone at least respond to the arguments so we can have a proper discussion?

[Colin Watson (cjwatson)]

There are lots of responses to the arguments in this bug log; the disagreements are essentially ideological. Opinion seems like the ideal bug status.

[Olaf van der Spek (olafvdspek)]

A response to #38 and #39 is still missing.

[Clint Byrum (clint-fewbar)]

Olaf, the point of the Opinion status is to allow discussion to continue without attracting the attention of triagers who are trying to categorize and/or reproduce issues in the New status.

So, to that point, the status should remain at Opinion until consensus is reached, at which point it should move to status Confirmed, or Invalid, but it should not return to New.

To that point, we should probably consider any bugs that are in the Opinion status and have received a lot of discussion for UDS sessions.

[Olaf van der Spek (olafvdspek)]

Ah, I assumed Opinion meant Wontfix. It'd still be nice if someone responded to the arguments.

[Søren (p-sl)]

I was horrified to find my home dir open, and Googled this post.

I simply can't believe the rationale - okay, we are geeks using Linux wearing tinfoil hats but please: you are going to sacrifice security for the sake of ... I don't exactly know how to put it... a badly implemented sharing feature, perhaps?

Running a webserver, I found out that if someone somehow manages to get shell access with the very limited webserver user, which runs silly rbash (restricted bash), they will have access to ALL users home dirs - also administrators.
But of course, then they will be pleased to see, how easy filesharing is on Ubuntu.

There must be a more intelligent solution to this security issue.

[Alexander Adam (7ql6)]

Sorry but the decision still doesn't make any sense to me.
I have to change the default permissions on every installation which is indeed *not* usability friendly.

Besides that the public-dir would be perfect for this (wouldn't it be possible to symlink public to a directory outside of users home and so leave it accessible for everyone?): I never ever intenionally shared files between home-dirs.
Addionally I have to add that I even talked with many colleagues and friends for this "feature" and (surprise surprise) they also don't use this "feature".

But many people doesn't know that a default ubuntu-installation behaves like this. And this is the real danger.
If you want a proof you can find many more people in the web who where negative surprised (besides the ones in this bug-ticket).
Wether in ubuntu forums, askubuntu.com, blogs or here on launchpad: obviously no one is expecting that.

And even IF Colin Watson amazingly really have more cases with public read access than private access then it should be at least decidable by the user (as mentioned by himself in #8). And I don't mean by /etc/adduser.conf but in the GUI (ie an checkbox in usermanagement wether the home-dir should be readable and/or a checkbox on the installer).

Furthermore like David Henningsson already said: if you have even a public dir wouldn't it be intuitive to expect that the other directories and files aren't public?

I totally agree with aysiu what the defaults should like and I also think like flaccid that even IF somewant WANTS to share his home-dir it is the worst idea to share files. There are thousands of possibilities but sharing the whole home directory should be the default?

Marc Deslauriers even if every tool which stores the permissions correct: as long as the user doesn't knows that his files are visible it is still an terrible issue - isn't it? If the user manages his files which leads to unintentinally public data there is definitely a need to improve something.

It was a phantastic step to offer simple solutions for encrypting the whole disk, home- or private-dir. But even if I have a fresh installation with an encrypted disk and I prohibited booting from usb or networking there could be a case like this:
I am booting the system (type the passphrase) and leaving the room for a moment than someone could login to the (default-activated?) guest login and steal my data. In this case the attacker needs nearly nothing for getting everything.
And even in "smaller" circles when family members share accounts on one computer they mostly expect their home dir is their little home - including a little amount of privacy.

And to complete the analogy in "real life". See the home-dir like a real home with your own room. Inner-flat doors are often lockable even if you know that these locks give just a low-level-security.

For a project which claims to listen to their customers: with all due respect but nobody seems to really listen here (or on ubuntu forums, askubuntu, …) while they are good reasons mentioned for a meaningful revision.

So Mark Shuttleworth: No facts or circumstances changed, because there are still many people who think that the default is wrong, b...

[Marcus Haslam (marcus-haslam)]

I will be out of the office until 9th January, in my absense please contact Nick Tait

On 14 Nov 2012, at 23:03, Alexander Adam <email address hidden> wrote:

> Sorry but the decision still doesn't make any sense to me.
> I have to change the default permissions on every installation which is indeed *not* usability friendly.
>
> Besides that the public-dir would be perfect for this (wouldn't it be possible to symlink public to a directory outside of users home and so leave it accessible for everyone?): I never ever intenionally shared files between home-dirs.
> Addionally I have to add that I even talked with many colleagues and friends for this "feature" and (surprise surprise) they also don't use this "feature".
>
> But many people doesn't know that a default ubuntu-installation behaves like this. And this is the real danger.
> If you want a proof you can find many more people in the web who where negative surprised (besides the ones in this bug-ticket).
> Wether in ubuntu forums, askubuntu.com, blogs or here on launchpad: obviously no one is expecting that.
>
> And even IF Colin Watson amazingly really have more cases with public
> read access than private access then it should be at least decidable by
> the user (as mentioned by himself in #8). And I don't mean by
> /etc/adduser.conf but in the GUI (ie an checkbox in usermanagement
> wether the home-dir should be readable and/or a checkbox on the
> installer).
>
> Furthermore like David Henningsson already said: if you have even a
> public dir wouldn't it be intuitive to expect that the other directories
> and files aren't public?
>
> I totally agree with aysiu what the defaults should like and I also
> think like flaccid that even IF somewant WANTS to share his home-dir it
> is the worst idea to share files. There are thousands of possibilities
> but sharing the whole home directory should be the default?
>
> Marc Deslauriers even if every tool which stores the permissions
> correct: as long as the user doesn't knows that his files are visible it
> is still an terrible issue - isn't it? If the user manages his files
> which leads to unintentinally public data there is definitely a need to
> improve something.
>
> It was a phantastic step to offer simple solutions for encrypting the whole disk, home- or private-dir. But even if I have a fresh installation with an encrypted disk and I prohibited booting from usb or networking there could be a case like this:
> I am booting the system (type the passphrase) and leaving the room for a moment than someone could login to the (default-activated?) guest login and steal my data. In this case the attacker needs nearly nothing for getting everything.
> And even in "smaller" circles when family members share accounts on one computer they mostly expect their home dir is their little home - including a little amount of privacy.
>
> And to complete the analogy in "real life". See the home-dir like a real
> home with your own room. Inner-flat doors are often lockable even if you
> know that these locks give just a low-level-security.
>
> For a project which claims to listen to their customers: with all due
> respect but nobody seems to reall...

[Alexander Adam (7ql6)]

I just wanted to add that I was wrong with the default guest login. The default guest login is *not* able to view others home-directories (the other points I mentioned are unfortunately still right).

[Bruno Nova (brunonova)]

I think the current permissions are not perfect.

On one hand, I understand that locking down the home folder (700 permissions) would create some problems.
Samba wouldn't be able to share any folder inside ~/ to other users (especially guest users), Apache wouldn't be able to access ~/public_html (if using Apache userdir module), users would have difficulty sharing files and folders to others and be confused, etc.

On the other hand, this is a privacy/security issue. Most people think that their home folders are private.
At least the guest session cannot access /home, and encrypted home folders are private, so it's not completely terrible.

In my humble opinion, the home folder should remain open (755 permissions), but all default folders and files inside (including ~/.config, ~/.local, etc.) should be made private (700 permissions) by default, except ~/Public.
Users can then change the permissions to share something, or move the files to ~/Public.
The file manager could also warn the user, in the permissions tab, when a file/folder, according to its permissions, should be accessible by others/group, but isn't because the parent folders are not accessible (fixing some confusion).
This would probably mean patching xdg-user-dirs-update and other stuff.

If not, the users should at least be warned that everyone can access their home folders.
This could be achieved by adding an information/warning balloon/tip to the file manager when it's in the home folder (like Nautilus does in ~/Templates), and if it's world readable (but allow the warning to be dismissed).
The warning could also be added to the "encrypt home folder" option during the installation: if it's not selected, warn the user that the home folder will be accessible by other users.

As a side note, it would be awesome if the file manager could show and manage ACLs (and setuid, setgid and sticky bits) out of the box, like KDE's Dolphin does. This would make sharing files with a specific user even easier.
"eiciel" adds ACL support to Nautilus, but it's not installed by default.

[Mehmet Atif Ergun (mehmetaergun)]

This needs to be reconsidered. All user comments in this thread refuse the official explanation given in comment #1

[Victor (blindvic)]

In the server edition this should not be enabled.

[Chris Rainey (ckrzen)]

Wow! Approaching 13-years and counting on this bug. Neat.

Desktop Linux: The principle of least astonishment (POLA) should _always_ be priority-one with Security. Open $HOME's are a surprise to me and everyone I know.

Now that cloud storage has taken the desktop users of the world by storm, is the need to have open(r-x) $HOME dirs still needed?

We've lost the 'Guest" user login since 18.04 and we've lost ecryptfs as an option in the installer. Why not just throw a simple toggle into the installer, to surface this issue, offering admins the option?

[Robie Basak (racb)]

> Wow! Approaching 13-years and counting on this bug. Neat.

What's your point in making this statement? A decision was made soon after the bug has filed and that decision still stands today. What does the age of the decision have to do with it?

> Why not just throw a simple toggle into the installer, to surface this issue, offering admins the option?

There are negative UX consequences of every "why not just ask the user" in the installer. It's not reasonable to demand that the user receive an education on using the system before being allowed to install it, which is what used to feel like to install Debian around the time Ubuntu launched (I don't know what the Debian installer experience is now). Part of the point of Ubuntu was to do the sensible thing and not ask a million questions. I am not looking to make a statement either way on this particular decision. My point is merely that there *is* a UX downside to "throw a simple toggle into the installer" and you are in competition with a bunch of other Ubuntu users who want _their_ question asked by the installer because they don't like some other default.

[Chris Rainey (ckrzen)]

Whoa...Robbie, I'm just looking out for all the new user's and admin's that are coming in from other platforms that could reasonably be surprised by this and not Unix/Linux veteran's who broke their teeth with vi on Slackware, etc..

Believe it or not, with WSL-2 and other notable advancements of Ubuntu coming on to the radar of mainstream and mostly Microsoft-trained admin's, we have an _opportunity_ here to create mindshare and loyalty for migrations of huge workloads to our platform-of-choice and, arguably, the best platform for safer and more secure computing as opposed to having the majority of PC users in the world stay on one company's monoculture-vision of desktop computing.

I'm attempting to spread the Gospel-of-GNU(Ubuntu) everywhere. We're on the same team, my friend.

Obscure wiki articles and 13-year old "opinion"-marked bugs will _not_ be the first place new admins or users will find out about this issue!

Heck, I've been a Linux user since 2004("Red Hat 8"(before Fedora was even a thing) box-set purchased at a CompUSA store), then Slackware and an Ubuntu convert since 2012 or so. I should know better than to leave multi-user seats unaudited for permissions after creation(or even during by not having edited the adduser.conf file). But even I just _assumed_ that a modern desktop would surely put security ahead of convenience! I didn't even know that this "security" issue was a "feature" till I started setting-up multi-user local seats and even then--I may have just started using ecryptfs as a workaround. Now--even that option is gone from user(admin)-facing installer widgets.

Put yourself in the shoes of a new or migrating small to medium sized business CIO or IT-manager looking to convert from the soon-to-be out-of-service "Windows 7" in order to keep fleets of older boxes running for daily knowledge-worker or office-productivity users who share desktop PC's over the course of 24/7 shifts at the office. What would you think if every system that you had installed or understood to be the out-of-box defaults for the past few decades was based on blocking vs allowing? And you took the risk of allowing this "Linux-thing"(yes...this is what I have heard it called many times) only to discover the opposite, a permissive rule set, without any warning.

Ubuntu is growing rapidly...I want to see it succeed despite it's geeks-only reputation. I think sensible defaults are good to always be working on(not just "opining" about in 13-year old bugs).

[Chris Rainey (ckrzen)]

If I invite you into my house(physical), then I don't expect you to go through my filing cabinets or closets, when I'm not looking, without explicitly giving you those "permissions(0755)".

"Good fences make good neighbours" and "Locks keep out only the honest" are equally true.

Placing convenience-over-privacy, by default, in this post-GDPR / Facebook & Twitter leaks / Equifax breach / Edward Snowden & Julian Assange(perhaps heroes to those of us in the USA), etc. seems to be unconscionable.

[Chris Rainey (ckrzen)]

It has been my experience, lately, that individuals or families sharing a computer have a single login account, i.e. "Family", etc.. This is probably due to the perception by such simple-needs $USER's or their family I.T. guru, that--it is the easiest way to overcome the reasonable and appropriate account isolation techniques, by default, in Windows or macOS. I suggest that the same could be true for Ubuntu and it would hardly be noticed, except by experienced *nix $USERS, most of whom--would already know how to twiddle the appropriate bits, if needed, to open their $HOMES.

[Jaime Hablutzel (hablutzel1-h)]

It really surprises me (negatively) that most Ubuntu experts seem to agree on this design decision. Isn't a well accepted fact that security can affect usability?.

Now, about:

> We assume that the people who share the machine are either trusted, or in a position to hack the machine (boot from USB!) trivially.

That assumption is not correct for me, for example, when I lend my computer to someone else, I don't usually trust them completely (so I'm still sitting near enough so they can't boot from an USB without being caught) and I just want to share with them the minimum they need to get their work done and having access to my personal files is not part of what they require.

And about:

> Now, in a more complex environment, like a university machine with many users, people do not have access to the hardware and can't easily root the box, but they also have the sysadmin skills to change the default permission.

I think that it doesn't hold a totally valid point as sysadmins like me tend to think that the default system settings are always secure enough for most regular deployments, so you don't think it is a good idea to change those settings unless you've read a thread like this one... which not everyone is willing to look for and then read.

Finally, it seems to me that this default setting damages Linux reputation (for non-experts) of being a secure OS.

[Dan (the-dark-aardvark)]

Just chiming in here to add my support for this.

I don't think there's anything more to say really. It's already been said very clearly why this should be changed. We should always have privacy by default.

It genuinely boggles my mind that there would be any opposition to this.

[Alex Murray (alexmurray)]

Updates for adduser and shadow were both uploaded to hirsute-proposed yesterday as per https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2021-January/018901.html:

https://launchpad.net/ubuntu/+source/shadow/1:4.8.1-1ubuntu8
https://launchpad.net/ubuntu/+source/adduser/3.118ubuntu5

shadow has already migrated to the release pocket, and with any luck adduser will migrate soon too which should resolve this issue.

[Giovanni Pelosi (hute37-gmail)]

Probably, behind the original decision there were also issues of home access, required by some unprivileged services, like apache (userdir).

Today, letting all users accessing any ~/Doc,~/Pic,~/Video look like a huge security hole (MS Windows deny this).

But anyway, today 'user' access should support user namespaces (subuid/subgid)

This is required for rootless container development (podman, docker).

Another point is "sandbox model" by snap/flatpak.

In particular in "partial" supported scenarios: Snap+SeLinux (fedora) and Flatpak+AppArmor (ubuntu)

[Giovanni Pelosi (hute37-gmail)]

The issue with rootless podman userns mapping is described here (postgres db confined in host user home):

https://www.redhat.com/sysadmin/rootless-podman-makes-sense

[Launchpad Janitor (janitor)]

This bug was fixed in the package adduser - 3.118ubuntu5

---------------
adduser (3.118ubuntu5) hirsute; urgency=medium

  * Enable private home directories by default (LP: #48734)
    - Set DIR_MODE=0750 in the default adduser.conf
    - Change the description and default value to select private home
      directories by default in debconf template
    - Change the DIR_MODE when private home directories is configured via
      debconf from 0751 to 0750 to ensure files are truly private

 -- Alex Murray <email address hidden> Wed, 06 Jan 2021 16:46:50 +1030

[Mark Shuttleworth (sabdfl)]

On 18/01/2021 12:46, Launchpad Bug Tracker wrote:
> This bug was fixed in the package adduser - 3.118ubuntu5
>
> ** Changed in: adduser (Ubuntu Hirsute)
> Status: Fix Committed => Fix Released

\o/

Well done and thank you to everyone who worked to make this happen.

I wonder if there will ever be another LP bug <50k that gets fix-released?

Mark

[DanielT (daniel-taylor)]

Hello, I’m original bug reporter back from 2006 and I’ve been watching the development of this bug over the years and I just wanted to say a big thank everyone for getting this sorted!

- Dan

[ceg (ceg)]

--- Avoiding the caveat of "this does not work"? ---

You may just not have thought yet of this solution that can be implemented with little adjustment:

( Privacy by default? YES, even with improved usability! )

Here is a trial script:
https://salsa.debian.org/freedombox-team/freedombox/-/snippets/518

The privacy by default solution goes along these lines:

* Simply let $HOME point to /home/<user/private

While having usable sharing dirs like this:

* /home/<user>/public_html
* /home/<user>/incoming

* /home/group/users/

* /home/group/admin/private
* /home/group/admin/incoming

These kind of different problems just need to be seen and solved together.

[ceg (ceg)]

Just two things that are broken with DIR_MODE=0750

(Which are still perfectly supported with the proof-of-concept
lock-down plus improved-usability script from last the post.
Independently from the additional group directories that it
introduces.)

* samba usershares
* ~/public_html

[Alex Murray (alexmurray)]

As noted in the discourse thread on this https://discourse.ubuntu.com/t/private-home-directories-for-ubuntu-21-04-onwards/19533 - I think a similar ACL approach should be able to be used to give the www-data user or similar access to your home dir for ~/public_html or for samba as needed.

[Alkis Georgopoulos (alkisg)]

Schools have started installing/upgrading to 22.04.1 and we're just now seeing this.

This change takes away the ability of the users to share some of their data WITHOUT involving the administrator.
It's not "privacy by default", it's "mandatory privacy".
Privacy by default could be done with umask or with a pam script that ensures the sensitive subdirectories are 0750.

Administrative actions can mitigate the issue, but they're tricky as they cannot easily be applied to users that haven't logged in yet and folders that don't exist yet.
Sudoer scripts that would give the ability to the users to share stuff by themselves can be a worse security risk.

On the other hand, encrypted home directories is a trend with similar issues.

I guess it'll be a bit easier to rewrite all the "system-wide" programs that need access to /home/username to use other locations such as /run/user/XXX, /home/shared/XXX, /home/public_html/XXX, /var/lib/AccountsService/users/user/face.png, /var/spool/* etc,
than to introduce an XDG specification for a new /home/user/private directory, and rewrite all the programs that need private or encryped data to use that one. That would be a much cleaner solution, but it can't be a goal for a single distribution.

So while this change does require us to spend some weeks reimplementing our shared folders software, it might be for the best, let's see how it goes.

Btw, the XDG_PUBLICSHARE_DIR="/home/user/Public" directory doesn't make any sense anymore after this change.
It might be worth it to try to standardize it to /home/Public/user/ instead, and see if other distributions will follow suit.
Then web servers and similar software could start using $XDG_PUBLICSHARE_DIR/public_html instead of ~/public_html.
Of course adduser etc will need additional patches to create the /home/Public/user folders, and delete them on deluser.

[Janto Dreijer (jantod)]

Great! Thank you for prioritizing the user's privacy!

[Seth Arnold (seth-arnold)]

On Mon, Sep 12, 2022 at 07:39:37AM -0000, Alkis Georgopoulos wrote:
> This change takes away the ability of the users to share some of their
> data WITHOUT involving the administrator.

Hello Alkis, do note that it is typical for users to own their own home
directory; if a user wishes to share, they can run:

chmod 755 ~
or
chmod 751 ~

(The choice is based on whether they want to allow listing their home
directory or not.)

Of course, they'd be wise to inspect the permissions on their other
files and directories to make sure they're only sharing what they intend
to share.

Of course, if the local administrator has decided that users cannot own
their own home directories, then that's another question entirely, one
you'll need to take up with the local administrator.

Thanks