umask in /etc/profile

[helder]

Hi,

I've just noticed that on the last line of /etc/profile I have a "umask 000". Now, I've made extensive changes to my B2 so I would like to know if this definition came in the factory install or if it was product of one of my changes.

This is a very unsafe setting, so if it's on the factory install it should be changed, if not I must find how did I do such a thing!

Thanks,
Helder

[gibban69]

I can confirm that factory setting is "umask 000". That seems very dangerous (and I just experienced that a user accidently deleted a file owned by another user). Why is it like this?
I suggest changing it to 022.
This is what the file looks like at delivery.

# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).

if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games"
fi

if [ "$PS1" ]; then
if [ "$BASH" ]; then
PS1='\u@\h:\w\$ '
else
if [ "`id -u`" -eq 0 ]; then
PS1='# '
else
PS1='$ '
fi
fi
fi

export PATH

umask 000

[helder]

Thank you for your answer.

Can someone from Excito explain why we have this default?
- This is more than two years old, maybe it's fixed on newer bubbas, if that's the case disregard this question.

[johannes]

Hi,

Carl is on vacation now so I can't verify, but this is how I think it is: When user 'user' create files (i.e. in /home/storage) they should be r/w for all users, this is our general idea. Then there are more specific rules for the /home/user (read for all but not write) and /home/user/private (no access for other).

Does this explain anything?

[helder]

Hello,

It explains a bit. However I think it is not necessary to grant this kind of permissions. What I usually do when I have to solve similar problems is:

• Each user has its own group, this is the user's default;
• Besides this, each user will belong to one or more additional groups, for example sake lets assume the user belongs also to a group named "users".

Now, if I want the user to have its home directory readable (but not writable) by others I will make it:

Code: Select all

$ ls -ld /home/helder
drwxr-xr-x 179 helder helder 16384 Jun 23 15:41 /home/helder

If I want to have a private directory within, I (or the user) can do:

Code: Select all

$ ls -ld /home/helder/private/
drwxr-x--- 2 helder helder 4096 Jun 23 15:45 /home/helder/private/

For this to work the file-creation mask must be 0022.

If I want to have a common directory I'll do something like:

Code: Select all

$ ls -ld /archive
drwxrws--- 2 helder users 4096 Jun 23 15:45 /archive

Note the sgid bit. For this to work the file-creation mask must be at least 0002.

Usually I consider the home directory completely private. This way I can just set the umask to 0007.

[johannes]

HI again,

I checked with my developer and this setting is a heritage from the default debian setting back in the good old days, and we never found reasons to change it. The normal usage for our product is not command-line but other file transfer protocols, where umask is irelevant. If you like to it's probably not a big issue to crank it up.

[helder]

Hello,

If you like to it's probably not a big issue to crank it up.

If anything, for correctness sake I think you should take care of this. Besides, It might not be the normal usage but there is a group of users who do not use the Excito customizations, for those users it's important.

Helder

[johannes]

Of course, this is for investigation for our next release, but this won't happen very soon, that's why I ment you could do it yourselves until then.

[helder]

OH, OK!

Not a problem for me, thank you.

[damike]

Hi everyone,

I know Excito is formally already aware of this issue, but I am of the opinion that they (grossly) underestimate the gravity of the problem. I regularly use the B3 via the shell and I usually su to root. I was *shocked* to see that every file or directory I create as root is readable and writable for everyone. That just defeats the purpose of the root account...

I bring this up again because earlier in this post it was said that the issue would be "for investigation for our next release". That was half a year ago.

I hope Excito will fix this issue soon. It only requires uncommenting 1 line in /root/.bashrc .

Otherwise, I'm very happy with my B3! Keep up the good work!

[Gordon]

I think the concept of the storage folder enforces the setting of this umask, and there may be other reasons that require files to be (write) accessible to more than the owner or even the group that the owner belongs to (e.g. user admin's primary group is admin while everyone else is in group users).

As a default for what the B3 is intended for, I think the umask 000 is acceptable. If you don't like it, just change it but keep in mind that this may lead to unexpected "locked" files in your homedir. Alternatively you could do what I did and enable ACL's to control who may do what and where.

[Ubi]

the purpose of the root account is not just so you can make files that nobody else can read. Early versions of UNIX did not even have umask, and by default the rm command still does not ask for confirmation. POSIX systems trust that you are careful and thorough when being root, and does not bother you with pesky limitations

[johannes]

Just wanted to say that we are following this discussion. This was never changed following the older discussion since it has some difficult implications just as Gordon suspects.

My view is that responsibility follows with root access, and since we don't allow root do do anything without first typing 'su' (making reasonably sure people who don't know what they are doing won't get this far) this should not be a big issue. However, if we indeed are misleading you high-skilled techy guys with this setting and making you do stuff you didn't intend we have a problem. However, judging from Gordons and Ubis responses, I suppose this isn't the case, right?

[Ubi]

Well in all honesty, things like leaving roots umask as 0000 and having an empty mysql root password are not good form and should be frowned upon a little bit. Are they a sercurity risk for a factory-delivered machine? No. Are they important enough to hold development on (for instance) the B2 2.4 release? Surely not.

[Christian]

I am heavily using (and enjoying) shell access, too - for me the B3 is a Linux server with the additional benefit of being a NAS (and not vice versa) - this is why I prefer it so much over the other NAS manufacturers' devices.

That being said, I was a bit surprised finding files being world-writable. Actually, at once I changed the umask command in /etc/profile to "umask 022" without much thinking. - After all, /etc/profile is executed only for login shells. So changing the umask there cannot harm anything, or anyone - or, at most, people logging in to the shell, and those, by definition, know what they are doing.

Since /home/storage/ is rws for group "users", a compromise would be umask 002. This way, every file a (non-root) user copies to /home/storage would be readable and writable by all other users, too, neatly fitting the expectation that /home/storage is fully accessible to everybody.

Best regards,
Christian