Upstart overrides the user's umask

Hi Reuben - thank you for reporting this bug and making Ubuntu better!

You are right: Upstart does reset the umask to 022 in a jobs environment unless the umask stanza has been specified in a job. This is correct behaviour for Upstart running as PID 1 but when running as a Session Init it really should inherit the current umask and use that for all jobs by default.

For consistency and backwards compatibility, we should also add a '--no-inherit-umask' option.

Actually, '--no-inherit-umask' is not required: the existing '--no-inherit-env' is sufficient'.

This also seems to be the cause of my umask setting being ignored. My umask is set through pam_umask and the GECOS field of my user.

Where would the override-file have to be placed as a workaround? I tried ~/.config/upstart as per the upstart session documentation and even /usr/share/upstart/sessions but to no avail.

Override file is for X session, e.g. for GNOME: ~/.config/upstart/gnome-session.override

does this bug also effect settings in /ets/login.defs ?
i specified "UMASK 027" there and it has no effect any more.

See above: upstart resets the umask when it starts the user jobs environment.

This bug was fixed in the package upstart - 1.11-0ubuntu1

---------------
upstart (1.11-0ubuntu1) trusty; urgency=low

  [ Dmitrijs Ledkovs ]
  * Run as much test-suites as possible, before exiting with failure.

  [ James Hunt ]
  * New upstream release.
    - the global environment is now serialized on re-exec. LP: #1238078.
    - fixes support for upstart-file-bridge detecting directory creation.
      LP: #1221466.
    - Fixes upstart user session to not override the user's configured
      umask. LP: #1240686.
    - Makes the session init available on the session dbus.
      LP: #1203595, #1235649.

  [ Steve Langasek ]
  * Document the authoritative Vcs branch in debian/control.
  * Update Standards-Version to 3.9.5, no changes required.
 -- James Hunt <email address hidden> Fri, 15 Nov 2013 13:16:56 +0000

Thanks very much for this, all concerned.

Is there a workaround for saucy, since this bug makes it impossible to have a shared subversion repository for different users. And we cant wait for trusty.
A global workaround, that also works in a KDE environment would be preffered

On 19 November 2013 15:21, Andreas Blochberger
<email address hidden> wrote:
> Is there a workaround for saucy, since this bug makes it impossible to have a shared subversion repository for different users. And we cant wait for trusty.
> A global workaround, that also works in a KDE environment would be preffered
>

Without SRU of upstart, the only work around I can think off is to
disable upstart for the user-session, by commenting out the desktop
session from /etc/upstart-xsessions.

Regards,

Dmitrijs.

Can someone add the package upstart - 1.11-0ubuntu1 to ubuntu backports?

btw. I do not feel this bug as low urgency, if upstart granted other users at a multiuser os by himself read access to my home directory.
Someone else may not recognize this.

Excerpts from asgard2's message of 2013-12-01 10:49:45 UTC:
> Can someone add the package upstart - 1.11-0ubuntu1 to ubuntu backports?
>

We don't use backports for important bug fixes. We use the stable
release updates (SRU) process.

Please click "Nominate for series" and choose a still supported series
that you think deserves the fix backported to it. Even better, backport
the merged patch to the version of upstart in that series, and upload
said patch here.

https://wiki.ubuntu.com/StableReleaseUpdates

Clint Byrum (clint-fewbar) wrote on 2013-12-02:
> Please click "Nominate for series"

There's no such button.

Excerpts from Keith Baker's message of 2013-12-03 06:13:24 UTC:
> Clint Byrum (clint-fewbar) wrote on 2013-12-02:
> > Please click "Nominate for series"
>
> There's no such button.
>

Ahh, this is one of those really weird, annoying launchpad bugs. This is
because you're viewing it in the upstart, rather than Ubuntu, context.

If you change the url to:

https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1240686

The link will appear.

Thanks for the hint, but I'm not eligible to nomiate for the bug.

This is just ridiculous. The damn ubuntu bureaucracy makes me want to change distribution more and more!

BTW: A bug in the bug tracker. Notice the irony?

Excerpts from Keith Baker's message of 2013-12-03 19:32:26 UTC:
> Thanks for the hint, but I'm not eligible to nomiate for the bug.
>
> This is just ridiculous. The damn ubuntu bureaucracy makes me want to
> change distribution more and more!
>
> BTW: A bug in the bug tracker. Notice the irony?
>

I notice the frustration, and I'm really sorry that you're going through
it.

Which release did you want it backported for, and I will gladly nominate
it for you (I would have expected anybody logged into launchpad would
be able to nominate, so that may also just be a permissions issue).

Thanks again!

I'd really appreciate the fix in the current release: saucy.

Ok Keith, thanks for sticking with it. Note that backporting non-Critical fixes to Saucy will likely be a low priority for Ubuntu developers, as it is only supported for 9 months. So if you can isloate the patch, and build/backport it yourself, that will be much easier as the developers will just have to review/upload it for you.

I'm afraid that that technical hurdle is a bit too high for me.

FWIW I have managed to fix this issue by manually installing upstart 1.11-0ubuntu1 for Trusty, as published here:
https://launchpad.net/ubuntu/trusty/+package/upstart

@dav.garcia

That's not a solution, but a hack.

@keibak -- Why do you say it is a hack?

@dav.garcia -- Originally you were reluctant to do this with the package:
Install with:
sudo dpkg -i upstart_1.11-*.deb
Reboot

Do I understand that you were successful with the above install?

@bab1

I think that is not a proper way to replace a package. If I install it manually from another release cycle or even distribution, I bypass any security updates from the apt repository.

It's straightforward to install packages from another distribution or release with updates. See https://wiki.debian.org/AptPreferences

This is a relatively minor bug with a straightforward workaround, so it has not been backported to saucy, which in any case only has a 9-month life. It is fixed in trusty. If you really want the fix, you can install it.

As the original reporter, I'm happy that the bug was quickly found and fixed, and I'm quite content with the workaround I found until Trusty is released. I'd rather the Ubuntu devs were doing other things than backporting this fix to saucy.

Well. I didn't (and still don't) think of it as a hack. Thank you Ubuntu developers (@clint-fewbar et al)for at least updating for Trusty is such a way that we can just apply the package to earlier versions (13.10). Boo for creating the problem in the first place. :)

I asked because I am advising a 13.10 user. I personally run 12.04. and will go to 14.04.1 so I personally won't see any of this.

@rrt Thank you for being that original reporter. I advise lots of folks about how set up group shared data. Altering the way umask works in the end is not a minor error at all. Yes there are workarounds and hacks. I prefer the system to deliver the umask I set.

Thank you Ruben, David and Kieth for your comments.

I didn't say "minor error" (I would prefer "minor problem"), I said a "minor bug". The problem is indeed major (in my case, it risked serious information leakage), but the bug is minor (because it has a simple and effective workaround).

Note that the fact that the trusty package can be installed in saucy is fortuitous: the maintainers didn't make any particular effort to ensure this would be possible.

I didn't say that YOU said any thing in my previous post. In fact I said: " Altering the way umask works in the end is not a minor error at all. "

The "altering" was by Ubuntu Devs. and I agree it is not a minor issue, error , problem or bug.

Thanks for the considered thoughts.

"I didn't say that YOU said any thing in my previous post": by making the comment "Altering the way umask works in the end is not a minor error at all" in a paragraph addressed to an earlier comment of mine, you implied that I had described it as a minor error.

In any case, I was attempting to contrast two different things, which I believe you conflated, and still conflate when you say "I agree it is not a minor issue, error, problem or bug." Indeed, I'm not sure with what you're agreeing, as I went to some lengths to distinguish this issue's potential seriousness as a problem from its minor nature as a bug (similar to the distinction between risk and hazard). It seems, rather, that we disagree on this!

However, such agreement and/or clarification is not really needed for this bug report, so I'll shut up now.

""Altering the way umask works in the end is not a minor error at all" in a paragraph addressed to an earlier comment of mine, you implied that I had described it as a minor error."

Actually I never saw that comment. :-)

Your good, I'm good. I'll shut up too!

I've just noticed that all my new files are becoming readable by anybody, because the default umask is 022, and my personal umask, set in .profile to 027 is getting ignored. Is this a consequence of this bug?
If so, please fix. Exposing data in this way is not nice at all and this is not a minor bug.

There may be two different things going on here. The bug was fixed in upstart 1.11, some time ago.

On the other hand, I noticed (as you did) in the last few days that my new files were getting a umask of 0027, contrary to the upstart profile I had installed. Because of the timing, I suspect the GNOME 3.10 upgrade (which I received via the GNOME3-team PPA) somehow caused the workaround to stop working.

Since it was possible to install upstart 1.11 from trusty without pulling in other dependencies, I did so, which cured the problem, as the bug is fixed there and the workaround no longer needed.

saucy has seen the end of its life and is no longer receiving any updates. Marking the saucy task for this ticket as "Won't Fix".

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release