-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2021-08-01 a las 13:15 -0000, Giuseppe Fierro escribió:

I've returned to OpenSUSE after years and it was quite shocking to see the weird permissions for user's home directory.

I tend to agree. Default is: drwxr-xr-x 133 cer users 12016 Aug 1 16:45 cer/ It should at least be: drwxr-x--- 133 cer users 12016 Aug 1 16:45 cer/ - -- Cheers Carlos E. R. (from openSUSE Leap 15.2 x86_64 (Minas Tirith)) -----BEGIN PGP SIGNATURE----- iJIEAREIADoWIQQt/vKEw5659AgM/X2NrxRtxRYzXAUCYQbZ4Bwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJEI2vFG3FFjNcALQA/1qCXhgOiomkcO/TDQFe XMYiIIJ/HyGqC3IxcCsH01lLAP9LL121OSvRztOcrwT22rHf+AewjdsDPjkSAIao GksiFw== =iUoH -----END PGP SIGNATURE-----

On 01/08/2021 20.06, Jan Engelhardt wrote:

On Sunday 2021-08-01 19:29, Carlos E. R. wrote:

...

El 2021-08-01 a las 13:15 -0000, Giuseppe Fierro escribió:

...

I've returned to OpenSUSE after years and it was quite shocking to see the weird permissions for user's home directory.

I tend to agree.

Default is:

drwxr-xr-x 133 cer users 12016 Aug 1 16:45 cer/

It should at least be:

drwxr-x--- 133 cer users 12016 Aug 1 16:45 cer/

That's hardly better, other users can still look.

That's fine with me. I can move out of group "users" those users I do not want to look, or, I can put them or me in a group per user. But the minimum thing to do is to disallow "all", IMO. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))

On 01/08/2021 20.24, James Knott wrote:

On 2021-08-01 2:15 p.m., Carlos E. R. wrote:

...

...

That's hardly better, other users can still look. That's fine with me.

I can move out of group "users" those users I do not want to look, or, I can put them or me in a group per user.

But the minimum thing to do is to disallow "all", IMO.

I seem to recall at one point each user had their own group.

That's the default on other distros. It is a matter of choice, there are pros and cons for either. It would be nice if YaST would have a setting to choose which method we wanted.

That way you could add whoever was allowed to access your files.

To be picky, not you, but the admin :-p

  Again, others shouldn't be allowed access, unless you give it to them.  My systems are all single user (if you ignore my dog & cat), so it's not critical.  The last time I set up a multi user system was about 10 years ago and I thought the default permissions were different then.

No, they have always been the same on openSUSE for about two decades. I'm not sure about the "all have access", though. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))

Hello, Am Sonntag, 1. August 2021, 20:37:10 CEST schrieb Carlos E. R.:

On 01/08/2021 20.24, James Knott wrote: [...]

...

That way you could add whoever was allowed to access your files.

To be picky, not you, but the admin :-p

To be picky ;-) you can really change that yourself: - chgrp (to one of the groups you are a member of) - chmod - setfacl Speaking of setfacl - ACLs also need the group permissions not to be "---" (otherwise the ACLs will become "effective ---"). There's another (probably rarely used) thing that won't work with 700 permissions: ~/public_html aka http://localhost/~$USER For this, Apache will need permissions to access ~/public_html and at least needs x permissions for the home directory. Regards, Christian Boltz -- Sometimes I feel that using osc (and OBS) is like driving an alien space ship, full of nice features, but I cannot read the manual ;-) [Filipe in opensuse-packaging]

On 01/08/2021 20.54, Christian Boltz wrote:

Hello,

Am Sonntag, 1. August 2021, 20:37:10 CEST schrieb Carlos E. R.:

...

On 01/08/2021 20.24, James Knott wrote: [...]

...

That way you could add whoever was allowed to access your files.

To be picky, not you, but the admin :-p

To be picky ;-) you can really change that yourself: - chgrp (to one of the groups you are a member of) - chmod - setfacl

Ah! Can I? I'll have to try. As I always the root of my machines, I don't often need to... :-)

Speaking of setfacl - ACLs also need the group permissions not to be "---" (otherwise the ACLs will become "effective ---").

There's another (probably rarely used) thing that won't work with 700 permissions: ~/public_html aka http://localhost/~$USER For this, Apache will need permissions to access ~/public_html and at least needs x permissions for the home directory.

True, I noticed. I have to add the group used by apache via ACLs. Or, move that directory to somewhere else, which I prefer. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))

On Sun, Aug 01, James Knott wrote:

On 2021-08-01 2:54 p.m., Christian Boltz wrote:

...

...

...

That way you could add whoever was allowed to access your files. To be picky, not you, but the admin:-P To be picky;-) you can really change that yourself:

I know I can change it and have done so in the past.  My concern is having a user's home directory open to others by default. It's sort of like removing the curtains from your bedroom. ;-)

Your home directory is always open to others, I would never trust permissions for "security" reasons. It's to simple to overcome them. If you have important or expensive data, encrypt them. That's the only secure thing. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)

Hi, encryption is a nice thing to have but not all users are able to do quickly or are not too lazy to do. A simple situation is the follow:, I'm the only user of my system, desktop or laptop, so I don't care about system permission but one day my syster, wife, mother, girlfriend etc. ask me if he can use my laptop for something what I do is to quickly setup new user account right? But wait... he is by default in the same group and he can see all of my stuff, mail, photos, documents, etc. What I have to do now? Encrypt all my files in hurry? Remove him from users group? Change the permission of my home dorectory? Why I have to do this in hurry by myself when my system can do it from me by default? In my opinion sane home directory permissions should be like this: drwx------. 1 gspe gspe 352 Jul 31 23:05 gspe

You are thinking about an hacker having hands on my computer I'm thinking about casual user that maybe it's the first time that use a Linux system. Usually I want to to choose what I want to share and what not.

On Mon, Aug 02, Mathias Homann wrote:

Am Sonntag, 1. August 2021, 15:15:20 CEST schrieb Giuseppe Fierro:

...

I've returned to OpenSUSE after years and it was quite shocking to see the weird permissions for user's home directory.

How about switching to "user private groups" the way red hat does it?

For system accounts we do this even today already. So only a little step to do it for normal users, too.

it's a two fold thing:

1. each user has a dedicated primary group with the same name as their username 2. default permissions are 640 for regular data, use 0600 for sensitive stuff and home directories.

then, to give user fred read access to toms files: "usermod -aG tom fred"

So people either need admin access to usermod or they always need to look for an admin if you want to exchange files with one other person. I'm pretty sure the result will be that most people will use "644" then. I don't care if we have a shared users group or "private" groups, from a security perspective, the result is similar if people don't care about their permissions. But to argument with "security" is the wrong road, because this will not increase "security" by a single jota. Thorsten

Cheers MH

-- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102

-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)

On 02/08/2021 09.04, Giuseppe Fierro wrote:

Hi, encryption is a nice thing to have but not all users are able to do quickly or are not too lazy to do.

A simple situation is the follow:, I'm the only user of my system, desktop or laptop, so I don't care about system permission but one day my syster, wife, mother, girlfriend etc. ask me if he can use my laptop for something what I do is to quickly setup new user account right? But wait... he is by default in the same group and he can see all of my stuff, mail, photos, documents, etc. What I have to do now? Encrypt all my files in hurry? Remove him from users group? Change the permission of my home dorectory? Why I have to do this in hurry by myself when my system can do it from me by default?

Also, normally encryption does not protect you in this case, permissions do. Encryption does not protect you in this case because normally the encrypted partition or separate home is mounted, and thus they have access as to a normal home directory, unless permissions block them.

In my opinion sane home directory permissions should be like this: drwx------. 1 gspe gspe 352 Jul 31 23:05 gspe

Notice that in that setup the group gspe do not have any access. They should be instead: drwxr-x---. 1 gspe gspe 352 Jul 31 23:05 gspe -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))

On Mon, Aug 2, 2021 at 10:50 AM Thorsten Kukuk wrote:

On Mon, Aug 02, Mathias Homann wrote:

...

Am Sonntag, 1. August 2021, 15:15:20 CEST schrieb Giuseppe Fierro:

...

I've returned to OpenSUSE after years and it was quite shocking to see the weird permissions for user's home directory.

How about switching to "user private groups" the way red hat does it?

For system accounts we do this even today already.

So only a little step to do it for normal users, too.

...

it's a two fold thing:

1. each user has a dedicated primary group with the same name as their username 2. default permissions are 640 for regular data, use 0600 for sensitive stuff and home directories.

then, to give user fred read access to toms files: "usermod -aG tom fred"

So people either need admin access to usermod or they always need to look for an admin if you want to exchange files with one other person. I'm pretty sure the result will be that most people will use "644" then.

The private group was not about accessing other user's files. It allowed using group permissions to control access to shared project data. Because each user is in a private group, you can set umask to allow (full) group access by default; then you create a project directory with SGID bit and owned by the project group and assign users to this project group. So files created in this directory inherit this group and users in this project group have access.

I don't care if we have a shared users group or "private" groups, from a security perspective, the result is similar if people don't care about their permissions.

Different models are better suited for different workflows. Neither is inherently more secure than the other.

But to argument with "security" is the wrong road, because this will not increase "security" by a single jota.

Le 02/08/2021 à 10:39, Carlos E. R. a écrit :

On 02/08/2021 09.09, jdd@dodin.org wrote:

...

Le 02/08/2021 à 09:04, Giuseppe Fierro a écrit :

...

But wait... he is by default in the same group and he can see all of my stuff, mail, photos, documents, etc.

it's usually what is expected... to share photos.

don't forget anybody having hands on your computer can literally do all what he wants... including going root. Permissions are fake security on this respect

A visitor asking to use your computer will not do any of that.

who knows... on the most common case you will have to let him use your own account... who create an account for any visitor? jdd -- http://dodin.org

On 02/08/2021 11.28, jdd@dodin.org wrote:

Le 02/08/2021 à 10:39, Carlos E. R. a écrit :

...

On 02/08/2021 09.09, jdd@dodin.org wrote:

...

Le 02/08/2021 à 09:04, Giuseppe Fierro a écrit :

...

But wait... he is by default in the same group and he can see all of my stuff, mail, photos, documents, etc.

it's usually what is expected... to share photos.

don't forget anybody having hands on your computer can literally do all what he wants... including going root. Permissions are fake security on this respect

A visitor asking to use your computer will not do any of that.

who knows... on the most common case you will have to let him use your own account... who create an account for any visitor?

If it is for a moment, I let them use my desktop. Otherwise, no, I create a user. Or have one already prepared for guests. For example, some asks me now and then to manage her photos. Well, I have a user for her, even if it is me using that user, because that way her photos as fully isolated and I can use photo manager software that do not get confused with my own photos. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))

El dom, 1 ago 2021 a las 16:02, Carlos E. R. () escribió:

On 01/08/2021 20.54, Christian Boltz wrote:

...

Hello,

Am Sonntag, 1. August 2021, 20:37:10 CEST schrieb Carlos E. R.:

...

On 01/08/2021 20.24, James Knott wrote: [...]

...

That way you could add whoever was allowed to access your files.

To be picky, not you, but the admin :-p

To be picky ;-) you can really change that yourself: - chgrp (to one of the groups you are a member of) - chmod - setfacl

Ah! Can I? I'll have to try. As I always the root of my machines, I don't often need to... :-)

...

Speaking of setfacl - ACLs also need the group permissions not to be "---" (otherwise the ACLs will become "effective ---").

There's another (probably rarely used) thing that won't work with 700 permissions: ~/public_html aka http://localhost/~$USER For this, Apache will need permissions to access ~/public_html and at least needs x permissions for the home directory.

True, I noticed. I have to add the group used by apache via ACLs. Or, move that directory to somewhere else, which I prefer.

¿What happens with private home directories, like my case, that use the same home for 2 different distros? (Tumbleweed + Leap 15.3) Regards, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/

On 2021-08-02 09:04, Giuseppe Fierro wrote:

In my opinion sane home directory permissions should be like this: drwx------. 1 gspe gspe 352 Jul 31 23:05 gspe

I might have old knowledge but doesn't ~/.ssh/authorized_keys need to be 644 and $HOME 711? -- /bengan

These are some Linux distributions that I've tested in vm Fedora: drwx------. 1 gspe gspe 352 Jul 31 23:05 gspe Pop_OS: drwxr-x--- 20 gspe gspe 4096 Jul 22 12:24 gspe Manjaro: drwx------ 16 gspe gspe 4096 3 ago 13.09 gspe Clear Linux: drwxr-x--- 17 gspe gspe 4096 Ago 3 14:14 gspe

El mié, 4 ago 2021 a las 13:53, Matěj Cepl () escribió:

Dne 03. 08. 21 v 9:14 Bengt Gördén napsal(a):

...

I might have old knowledge but doesn't ~/.ssh/authorized_keys need to be 644 and $HOME 711?

More important is that ~/.ssh should be 700.

Since you are talking about permissions, I would like to ask you a question: With the AppImage Openshot application, when I try to render a video I get the error. "Could not create hardware device". If I try to render via GPU (VA-API), I get the error immediately, but if I render via CPU, the error appears at 1.79% of the processing. Is it a problem of permissions of the application? It is true that we can install Openshot from the Opensuse repositories, but due to a bug in ffmpeg 4.4, the rendered videos result without audio. Thanks, Juan -- USA LINUX OPENSUSE QUE ES SOFTWARE LIBRE, NO NECESITAS PIRATEAR NADA Y NI TE VAS A PREOCUPAR MAS POR LOS VIRUS Y SPYWARES: http://www.opensuse.org/es/ Puedes visitar mi blog en: http://jerbes.blogspot.com.ar/

Hello, On 2021-08-05 09:19, H.Merijn Brand wrote:

On Wed, 4 Aug 2021 18:52:33 +0200, Matěj Cepl wrote:

...

Dne 03. 08. 21 v 9:14 Bengt Gördén napsal(a):

...

I might have old knowledge but doesn't ~/.ssh/authorized_keys need to be 644 and $HOME 711?

More important is that ~/.ssh should be 700.

Yes, and $HOME only requires not world writable, so 0755 is ok for ssh

perhaps I misunderstand something special here but in general for privacy and security reasons $HOME must not be world readable to avoid that other users can read your personal or even private/secret data too easily. If other users (over)write or delete your data it is an annoyance (you must restore it from your backup) but when others steal your (secret) data all is lost. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer

Hello, On 2021-08-05 09:56, H.Merijn Brand wrote:

On Thu, 05 Aug 2021 09:29:17 +0200, jsmeix wrote:

...

On 2021-08-05 09:19, H.Merijn Brand wrote:

...

On Wed, 4 Aug 2021 18:52:33 +0200, Matěj Cepl wrote:

...

Dne 03. 08. 21 v 9:14 Bengt Gördén napsal(a): [...]

More important is that ~/.ssh should be 700.

Yes, and $HOME only requires not world writable, so 0755 is ok for ssh

perhaps I misunderstand something special here but in general for privacy and security reasons $HOME must not be world readable to avoid that other users can read your personal or even private/secret data too easily.

If other users (over)write or delete your data it is an annoyance (you must restore it from your backup) but when others steal your (secret) data all is lost.

Yes, so your $HOME might have more type of data

1. Things you want to share with anyone

$HOME = 0755 $HOME/public = 0755

e.g. tools and documentation that everyone may use

2. Things you want to share only with your group

$HOME = 0755 $HOME/project = 0750

3. Thing private to you and you only

$HOME = 0755 $HOME/private = 0700

I have ~/bin and ~/lib in group 1 I have ~/.ssh, ~/private and ~/work in group 3

Do you want your ~/.profile, ~/.bashrc, ~/.exrc, ~/.tcshrc etc readable by the world? Who knows, maybe you do, maybe you don't.

What do you set your umask to? Do you set it to the same on all the systems you work on? Do you have '.' in your $PATH? All kind of questions that you need to address when you want to protect your data.

And of course, you have a solid backup and you actually tested recovery

Remember what the subject of this mail thread is: "OpenSuSE should use private home directories by defaut" [sic!] Of course anyone can change the defaults to what he needs in particular because it's all truly free software, cf. the "useradd - adjust defaults to other tools and distributions?" mail thread here. Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer

On Thu, Aug 05, Carlos E. R. wrote:

On 05/08/2021 10.55, jsmeix wrote:

...

Hello,

On 2021-08-05 09:56, H.Merijn Brand wrote:

...

On Thu, 05 Aug 2021 09:29:17 +0200, jsmeix wrote:

...

Remember what the subject of this mail thread is: "OpenSuSE should use private home directories by defaut" [sic!]

Of course anyone can change the defaults to what he needs in particular because it's all truly free software, cf. the "useradd - adjust defaults to other tools and distributions?" mail thread here.

How can we, as root, change the defaults of our machines for users we create?

Look at login.defs and override the defaults via drop-ins in /etc/login.defs.d, so that they survivey an update?

Seeing that there is no agreement.

Why is an agreement necessary here if you as root want to change the defaults or your machines?

And how do we set the default properties of the directories and files users create under their own home? This is taken as so basic that nobody explains it.

Google shows me 766000 hits for this... Just start reading, I suggest to start with login.defs and UMASK.

I would be happy with home been group readable, but not world readable (by others)

echo "UMASK 027" > /etc/login.defs.d/umask.defs But this is also explained as example in login.defs. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)

On 2021/08/01 11:57, James Knott wrote:

On 2021-08-01 2:54 p.m., Christian Boltz wrote:

...

...

...

That way you could add whoever was allowed to access your files. To be picky, not you, but the admin:-P To be picky;-) you can really change that yourself:

I know I can change it and have done so in the past. My concern is having a user's home directory open to others by default. It's sort of like removing the curtains from your bedroom. ;-)

---- Just as a matter of being clear -- for home users, how many share their suse machine with someone in the general public? I mean, just how many other people would have access to a directory with 'other'=open? Also I still do setup groups = users for the most part. I sometimes have different UID's on different machines (for same name), but at least manage to have 1 group they are both in. Annoyingly, so many retarded utilities claim others have access to files and raise a "problem flag: system isn't using standard security policy and refuse to work. I've often thought of setting up a setuid script with executable access based on same group -- so effectively anyone in the same group could suid to another userid -- meaning primitive programs that believe rwx------ is the only correct way to enforce single-user access, could have their security policy turned on its ears and file it as a security bug for claiming that 700 is 'single user' when it wouldn't be. Slightly better is being able to setuid to the name of any user that had a same name group and that you were a member of. Thus only by enforcing groups with 1 user, could they assume an executable was only writable by one person. I said I've thought about it -- not that it seems to have tons of utility, but neither does applications trying to enforce their idea of a proper security policy on all the users of that application. For any record, though, having configurable system defaults certainly seems useful and allowing user (or admin) choice in what security policy to use.