0

I am using User Private Groups on a CentOS7 server and I can't seem to get things quite working.

Firstly the standard users seen to have a mask of 0022 and I am fairly sure it should be 002 for UPG.

The user has /bin/sh set in its /etc/password and has a uid/gid 1017.

The bit of /etc/profile setting umask is:

UID -gt 199 ] && [ "`/usr/bin/id -gn`" = "`/usr/bin/id -un`" ]; then
    umask 002
else
    umask 022
fi

/usr/bin/id -gn <> /usr/bin/id -un

But I quess this must be there for a reason. Not sure why this is here/if it is safe to remove.

I am assuming here that proftpd is using the users umask as this seems consistent with what is happening. The new files FTPd to the server are u+rw, g+rw, o+r.

So I think all I need to do is sort out umask for the user?

Ben Edwards
  • 341
  • 4
  • 13
  • The convention is that the user's private group name is identical to the user name. So user `ben` has a private group `ben`. The system expects this and all of the utilities both expect and conform to this. Rename your groups appropriately (or rather, put it back the way it was). – Michael Hampton Mar 21 '19 at 03:19
  • @ben-edwards: you should fix the title: Perivate to Private, i guess... – j.c Apr 28 '23 at 11:02

1 Answers1

0

Sadly You didn't wrote what You don't got working.

ProFTP has an own Umask configuration parameter which is sometimes defaulted to 022 which is a reasonable default, but if unset it uses System defined defaults.

In case of FTP-Daemons and such the settings are very likely not taken from /etc/profile or such because that are initialization files for the shells and FTP is normally unrelated to a normal shell. But there are more places, like for example PAM configuration where the same logic is applied as in the example profile script (USERGROUPS_ENAB in /etc/login.defs).

What also can happen, especially with SFTP, that the client defines permissions during transfer and the server does not enforce Umask then (but with ProFTPD YOu could configure it otherwise). Same can apply to FTP clients if the SITE CHMOD extensions are available for the user.

For the reason that the umask is is more loose with UPGs is that for Users that have a shared primary group as default it is much more important to have their own files and folders protected from modification by other group memebers which are likely to exists then by default. For UPG, I assume, this more loose default has the advantage, that in shared folders (with SGID set) the file are automatically writable by anyone but in other shared folder without SGID set no one can edit the files by default.

But as it is not really understandable what You want and why/whether, I cannot directly answer Your question what to do in Your case.

EOhm
  • 815
  • 3
  • 7