Hi,

Non system wide readable (home) directories should be 750, not 751.
Or, the question should be made more clear, for example by replacing readable by listable.

This one time, at band camp, Olaf van der Spek said:

That seems reasonable on the face of it.  Mark, opinions?  I'm willing
to go either way, although I think adduser is frozen, so this change is
unlikely to make etch without some prodding.

I think that 751 is still appropriate just in case one wants to make a
subdirectory group accessible. But I am unemotional here.

Greetings
Marc

Marc Haber wrote:
 > On Wed, Nov 15, 2006 at 05:56:42PM +0000, Stephen Gran wrote:
 >> This one time, at band camp, Olaf van der Spek said:
 >>> Non system wide readable (home) directories should be 750, not 751.
 >>> Or, the question should be made more clear, for example by replacing
 >>> readable by listable.
 >> That seems reasonable on the face of it.  Mark, opinions?
 >
 > I think that 751 is still appropriate just in case one wants to make a
 > subdirectory group accessible. But I am unemotional here.

In that case, could you change the question to a multiselect that also
allows 750 to be chosen?

That is a non-option for etch because it would invalidate translations.

After conferring with aba about this issue, it seems that nobody
besides you seems to have a strong opinion about this change, and I am
therefore inclined to say "don't change". I would appreciate if you
could bring this up on debian-devel so that we can see what is rough
consensus about this issue.

Please take ~/public_html into this consideration.

Greetings
Marc

besides you seems to have a strong opinion about this change, and I am
therefore inclined to say "don't change".

How do you view world-readable home dirs from a privacy and security
point of view then?

~/public_html is not part of a default Debian install. It's not even
part of a default Apache install.
I'd like to err on the safe side.

Olaf

Olaf van der Spek writes ("Default Homedir Permissions"):

I disagree with this conclusion, because I disagree with the
underlying implication that the general readability of files is not
needed.

Most installed systems have a smallish number of users who know each
other reasonably well and would like to be able to share files.  It
does not make sense to put strong privacy barriers in between those
users.  Sensitive data like email and browser histories are already
made non-world-readable.

So the default is correct.

Perhaps it might be reasonable to try to find a way for accounts like
msql and www-data not to be able to access home directories (add
"daemon" to their supplementary group list and set the permissions of
/home 0705 to root.daemon, perhaps), but is this really worthwhile ?
If it is, the right thing to do is to go away and think about exactly
how to do it, not to file a bug asking for the default home directory
permissions to be changed.

Ian.

What are those assumptions based on?
And how do you go from "want to share some files" to "default to share
all files"?

chmod 755 ~ is not a hard way to remove the barrier.

That would be another violation of general security principles (access
control based on exlcusion instead of inclusion);

The bug wasn't about that, although it was related.

…

There are obviously differences of opinion in our expectations of
"how secure" a default installation should be.

Should it be locked down like Fort Knox?

Should it be generally usable, and easy for users to see each other's
stuff?

In general, I think it's fair to say that the average Debian
installation does not require Fort Knox levels of security.  Simply
allowing other people to read our files is often something desirable;
if I have something especially secret, I'll take steps to make sure
it's not readable or writeable by anyone except me.  But in general,
it's not a bad thing that others can see my stuff.  I can always keep
private things in a 0700 subdirectory.

Even on the massively shared systems I use, it's common for home
directories to be readable by default, so you can let other people
access your data, scripts, git repos, or whatever.

I can see that in some circumstances you might well want total control
over who can see your files, but unless you're dealing with TOP SECRET
stuff, I am not convinced that this is something the typical user would
wish to have by default.  Are there any common use cases which require
this?


Regards,
Roger

This is easily accomplished using ACLs.  Example to only allow apache
access to public_html, and nothing else:

% setfacl -m g:www-data:x ~
% setfacl -m g:www-data:rx ~/public_html
% getfacl ~ ~/public_html
getfacl: Removing leading '/' from absolute path names
# file: home/rleigh
# owner: rleigh
# group: rleigh
user::rwx
group::r-x
group:www-data:--x
mask::r-x
other::r-x

# file: home/rleigh/public_html
# owner: rleigh
# group: rleigh
user::rwx
group::r-x
group:www-data:r-x
mask::r-x
other::r-x


Regards,
Roger

Does other refer to other users, all other accounts or the entire world?

You can, but you can easily forget that.
Note that defaulting to private does not prevent you from changing the
permissions.

Like backups, the need for security is often discovered after it was necessary.

It refers to S_IRWXO, which is what this bug is about.  What that
means in practice is up to you.
…

Yes, but like everything there is a tradeoff.  A totally secure system
is an unusable system.  Having to instruct every user how to relax the
permissions to allow others to access their files, or allow their web
pages to be visible, is effectively pointless make-work if that was what
you wanted in the first place.  And for most people, I would argue that
/is/ what is wanted.

Remember that historically, multi-user systems have been about sharing
and collaboration, not isolation in walled-off prisons.  I know which
type of system I want, and it's not the latter.

0755 is not inherently insecure.  Others can't make any changes, but
they can look.  The only issue here is accidental disclosure of
information intended to be private.

I would argue that a change that /would/ make a real difference, would
be to have (as an example) emblems in Nautilus that flag files and
folders depending on if other people have read or write access.  That
would visually show what is (and is not) secure either by intention or
by accident.


Regards,
Roger

Other (people) in "Simply allowing other people to read our files is
often something desirable" does not refer to S_IRWXO.

You're right, in that case it makes more sense to edit /etc/adduser.conf
Or to setup public dirs that people could use to share stuff without
defaulting to share their entire home dir.

Is it? A lot of people have desktops / laptops that aren't shared with
other people and that don't use the per-user public_html.

Historically security was not an issue.

Right

Agreed.
We have ACLs, but I believe that the local requirements vary enough
that it is not worth the effort.

You don't want to make it harder for users, but this is where design can
help. If we need to make a system which prevents cross user file
attacks, then we could fairly easily implement these things:

 * Shared Folder, directory which is available to all users where they
can put explicitly shared contents (MacOSX does this).
 * Make sure shared folders via smb/nfs are accessible, make it clear
that this would share files inside the system as much as on the network.
 * A program which allows temporary file access to another user's home
folder after the user have authorised the access.

Yes, but we don't make it clear that a user's home directory is a
free-for-all with all users. Folder indicators would be useful. But do
users know that they've signed up for this when they installed Ubuntu?

I think it's more likely that Ubuntu users think the data is protected
until the magic time when cross-user file access is demanded and then
it's unprotected for that one instance. Computers are magic after all.
Asking users would be key to answering that.

If public by default is the way we want to go, then why not have a
Private folder be default in the users home directory? Combined with the
indication emblem in nautilus; this might provide a space for users to
put data. ATM it's too hard to teach users how to secure a folder or
even how to set up an encrypted folder.

Martin,

Martin Owens wrote:

IIRC, Ubuntu has done some work toward providing such an encrypted
private subdirectory by default. Someone should look into pulling that
into a package in Debian.

I think this is an excellent idea, because the presence of a "private"
folder in the user's home implicitly implies that the rest of the
home is /not/ private, i.e. is self-documenting.  We could even put
a README file inside explaining what the purpose is, and how to change
the permissions should they want to.

We could even do the opposite (create a "public" folder) if the
permissions are 0750, though this would require either 0751 or
ACLs to be actually accessible.  Again, we could include a README file
instructing the user how to do this.

The Nautilus emblems idea is, I think, a fairly straightforward
exercise should we wish to do this.  I already puts "no entry" emblems
on folders you don't have permission to enter, so it's not a big
change to additionally flag up folders which other have read and write
access to.


Regards,
Roger

Or it could be a symlink to a public user dir outside of /home such
that 751 isn't necessary.

Olaf

On Sat, Feb 19, 2011 at 10:49 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:

Stephen?

Isn't it nice, having public home dirs by default? :p

http://lists.debian.org/debian-devel-announce/2012/01/msg00010.html

This might not be clear to all readers, we are talking about the Debconf
question that adduser asks on installation.

I am not sure whether we should keep that question. Most systems
installed nowadays are single-user anyway, and those who are installed
for multiple-users usually have administration that can change the
default in adduser.conf.

After deciding this, we need to decide on the default.

There is discussion going on in debian-devel about this.

Greetings
Marc

Hello,

Bug #398793 in adduser reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/adduser/-/commit/6d571d0abbf3a0fa363f548d24ff86edb7feb262
------------------------------------------------------------------------
Implement SYS_DIR_MODE.

Closes: #1008081
Closes: #202943
Closes: #398793
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/398793

We believe that the bug you reported is fixed in the latest version of
adduser, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 398793@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Marc Haber <mh+debian-packages@zugschlus.de> (supplier of updated adduser package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Wed, 13 Jul 2022 20:30:00 +0200
Source: adduser
Architecture: source
Version: 3.122
Distribution: unstable
Urgency: low
Maintainer: Debian Adduser Developers <adduser@packages.debian.org>
Changed-By: Marc Haber <mh+debian-packages@zugschlus.de>
Closes: 202943 239825 398793 432562 520037 521883 588872 643559 664869 675804 679746 685532 701110 723572 774046 849265 874560 891748 896916 908997 920739 923059 925511 926262 969217 977678 979385 983405 992163 1001863 1006897 1006941 1006975 1007785 1008081 1008091 1014395 1014448
Changes:
 adduser (3.122) unstable; urgency=low
 .
   [ Marc Haber ]
   * improve package description.
   * Standards-Version: 4.6.1 (no changes necessary)
   * clean out EXTRA_GROUPS to only contain users.
     Thanks to Daniel Keast. (Closes: #849265)
   * add SECURITY section to manual pages.
   * add test for backups of home directory.
   * improve and update lintian overrides.
   * Formatting changes to manual pages.
     Thanks to Markus Hiereth. (Closes: #874560)
   * fix some typos in manual pages.
   * set VERBOSE and DEBUG envvars in deluser as well. (Closes: #1006897)
   * add documentation about adduser being a policy layer. (Closes: #1007785)
   * try to clarify system account terminology (policy vs system).
     (Closes: #1006975)
   * Document that only adduser --system is idempotent. (Closes: #723572)
   * error out for two-argument addgroup.
     Thanks to Mike Dornberger. (Closes: #664869)
   * make --add_extra_groups into --add-extra-groups. (Closes: #1014395)
   * --force-badname is now --allow-badname. (Closes: #1014448)
   * update turkish debconf translation.
     Thanks to Atila KOÇ. (Closes: #908997)
   * Update Russian debconf translation.
     Thanks to Lev Lamberov. (Closes: #920739)
   * Update Danish debconf translation (Closes: #923059)
   * Update Italian debconf translation.
     Thanks to Luca Monducci. (Closes: #969217)
   * Update German man page translation.
     Thanks to Helge Kreutzmann. (Closes: #977678)
   * Update European Portuguese translation of man page.
     Thanks to Américo Monteiro. (Closes: #925511)
   * disable translated manpages, none left for the time being.
   * deprecate planned directory service support.
   * Add docs about adduser.local being the place to interact with DS,
   * Some improvements to autopkgtests.
 .
   [ Matt Barry ]
   * System account home dir defaults to /nonexistent. (Closes: #679746)
   * do not accept all-numeric user names. (Closes: #891748)
   * prompts need y/n/empty(default).
   * Implement SYS_DIR_MODE. (Closes: #1008081, #202943, #398793)
   * Implement SYS_NAME_REGEX. (Closes: #521883, #432562)
   * Deprecate SETGID_HOME.
     Add NEWS/TODO items. (Closes: #643559, #979385, #1008091, #643559)
   * Fix ignored files for --remove-all-files.
     (Closes: #1001863, #588872, #926262, #992163)
   * Redefines the default NO_DEL_PATHS to avoid unnecessary
     scanning.
   * Change deluser_files test to use gzip.
   * Fix deletion of sockets/pipes. (Closes: #685532)
   * Simplify checkname sub.  (Closes: #1006941)
   * Adds support for lock files. (Closes: #983405)
   * Username validity testing framework.
   * Add --allow-all-names to bypass --force-badname.
     (Closes: #520037, #774046)
   * use warnf instead of printf in some places. (Closes: #675804)
   * Support tar --auto-compress for backups. (Closes: #896916)
   * Many improvements to autopkgtests. (Closes: 239825)
 .
   [ Jason Franklin ]
   * Allow for cloned-UID users in group member lists.
     Thanks to Daniel Heimann. (Closes: #701110)
Checksums-Sha1:
 5cbcec9f80e5c73198307edb7040c5c12bb35d3f 1683 adduser_3.122.dsc
 ccf7c4e3efec29257e3b484bb53c2a55d69e0455 230224 adduser_3.122.tar.xz
 27c0ec7f2d7048ddfd7f89dc33012bef7a8e5866 5697 adduser_3.122_source.buildinfo
Checksums-Sha256:
 584ed616d8ac705daffc96564ef45fb34f2eb9663f7348013adea0e4539a869c 1683 adduser_3.122.dsc
 5f093054c0f0c90c313d704f7af6d338f334df793942fafd43e5a8e6c63236c4 230224 adduser_3.122.tar.xz
 7f92d3de2b5ea8da31088424a2043831dedc8aab8f60158e37455cb3a350d63e 5697 adduser_3.122_source.buildinfo
Files:
 0c7d4c5bcd648b829bcaa58101fecbb7 1683 admin important adduser_3.122.dsc
 1da1b75966877f902c4b6d0d5f105609 230224 admin important adduser_3.122.tar.xz
 ab9602ba5d83a6de88ab29bb2e76d961 5697 admin important adduser_3.122_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE6QL5UJ/L0pcuNEbjj3cgEwEyBEIFAmLPEWMACgkQj3cgEwEy
BELCfhAAujNsWZNpvvi2vpDICGMPprz7MooXq5B4fe6fR6nR5Pizh+0E9Skh7NVl
Z5qJvIzcNcva+/TYkml0wO77H1fPefQ+sgxCHmtUTBwK9LZPdh0b6MrWK7hWnhk0
QI/mRMKoNUrMSpVz6suvetUrHvVymWBv/hsQHTt5uSOAB/Wqwbfdt0VFYgQ2i+Yd
Vtr1+U4yjPZ+j9kAFg7HYnVc2Jh8J07ipRrSRnC07AB3wvwcunUiv2fOzJi4S51S
9n/LllsXNS4629siVKDspKOtaak3dpXRPLHFgB+hPlZRhdCCKWoto9TrY1e3XY8N
zZRSYVULaH9OkuIFx6yoUuChhDmteyZ+C0TJlv+qaigf34/qaqF15pu4ee5ZlmuT
SYHI2vcYQ0yXJ92U2U56hYvlzFZufyopWUQkALKwGEzq13LMlMtTJhKypl2PnwzF
jL/n0r0P92kSUd0BAFuzsdp3PPkQoTG9hSTf5BQAXN9JR1dYkIjc95si8KKZ+FD+
Gda+o46EUo3tLgAYGxStxoPsgNb8n2mePrFB5cXERL84uimeVNMg4Hnmt8+cqnYw
jbdDxODIBNsgoCYEqqTe2NOyBQv5gPb0PXYekiHNFRH70sTJDPIjQkrnrYQX73xZ
W5ap2XFEMpqGrFa8VyUwRl15/MAg5Ds0bRi7GzlGPKIKKK8PFFI=
=6vgg
-----END PGP SIGNATURE-----