Upstart overrides the user's umask

Bug #1240686 reported by Reuben Thomas on 2013-10-16
84
This bug affects 18 people
Affects Status Importance Assigned to Milestone
upstart
Undecided
James Hunt
upstart (Ubuntu)
High
James Hunt
Precise
High
Unassigned
Saucy
High
Unassigned

Bug Description

I set the umask in my ~/.profile. In previous releases of Ubuntu this worked nicely. Now, I find it has been reset from 0027 to 0022. On investigation, this appears to be upstart's fault. Setting

umask 027

in an upstart override file for my desktop session (gnome-session) restores the desired functionality, but obviously this is not ideal, as it's a duplicated setting (I still need the setting in ~/.profile, e.g. for terminal and ssh logins).

This sort of problem has been common in other parts of the stack in the past (e.g. gdm/gnome-session used to stomp on the user's umask too), so it's understandable that it comes up in upstart, but equally it would be nice to fix it!

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: upstart 1.10-0ubuntu7
ProcVersionSignature: Ubuntu 3.11.0-12.19-generic 3.11.3
Uname: Linux 3.11.0-12-generic x86_64
.home.rrt..config.upstart.gnome.session.override:
 # Duplicate this here as upstart overrides the user's umask
 umask 027
ApportVersion: 2.12.5-0ubuntu2
Architecture: amd64
Date: Wed Oct 16 21:10:47 2013
InstallationDate: Installed on 2011-05-24 (876 days ago)
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
MarkForUpload: True
SourcePackage: upstart
UpgradeStatus: Upgraded to saucy on 2013-10-10 (5 days ago)
UpstartBugCategory: Session
UpstartRunningSessionCount: 1
UpstartRunningSessionVersion: init (upstart 1.10)
UpstartRunningSystemVersion: init (upstart 1.10)
upstart.upstart-event-bridge.log: upstart-event-bridge: Disconnected from Upstart
upstart.upstart-file-bridge.log:
 Job got added /com/ubuntu/Upstart/jobs/unicast_2dlocal_2davahi
 Job got added /com/ubuntu/Upstart/jobs/update_2dnotifier_2dcrash
 Job got added /com/ubuntu/Upstart/jobs/update_2dnotifier_2drelease

Related branches

Reuben Thomas (rrt) wrote :
James Hunt (jamesodhunt) wrote :

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.

Changed in upstart (Ubuntu):
status: New → Confirmed
assignee: nobody → James Hunt (jamesodhunt)
Changed in upstart:
assignee: nobody → James Hunt (jamesodhunt)
James Hunt (jamesodhunt) wrote :

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

Changed in upstart:
status: New → In Progress
Brenden Bain (brendenbain) wrote :

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.

Felix Eckhofer (eckhofer) wrote :

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.

Reuben Thomas (rrt) wrote :

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

jan (jhennecke) wrote :

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

Reuben Thomas (rrt) wrote :

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

Changed in upstart:
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in upstart (Ubuntu):
status: Confirmed → Fix Released
Reuben Thomas (rrt) wrote :

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.

asgard2 (kamp000x) wrote :

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

asgard2 (kamp000x) wrote :

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.

Clint Byrum (clint-fewbar) wrote :

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

Keith Baker (keibak) wrote :

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

There's no such button.

Changed in upstart:
status: Fix Committed → Fix Released
Clint Byrum (clint-fewbar) wrote :

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.

Keith Baker (keibak) wrote :

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?

Clint Byrum (clint-fewbar) wrote :

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).

Keith Baker (keibak) wrote :

Thanks again!

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

Clint Byrum (clint-fewbar) wrote :

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.

Changed in upstart (Ubuntu):
importance: Undecided → High
Changed in upstart (Ubuntu Precise):
importance: Undecided → High
Changed in upstart (Ubuntu Saucy):
importance: Undecided → High
Changed in upstart (Ubuntu Precise):
status: New → Triaged
Changed in upstart (Ubuntu Saucy):
status: New → Triaged
Keith Baker (keibak) wrote :

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

David García (dav.garcia) wrote :

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

Keith Baker (keibak) wrote :

@dav.garcia

That's not a solution, but a hack.

bab1 (skeezix1947) wrote :

@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?

Keith Baker (keibak) wrote :

@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.

Reuben Thomas (rrt) wrote :

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.

bab1 (skeezix1947) wrote :

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.

Reuben Thomas (rrt) wrote :

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.

bab1 (skeezix1947) wrote :

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.

Reuben Thomas (rrt) wrote :

"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.

bab1 (skeezix1947) wrote :

""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!

Sergio Callegari (callegar) wrote :

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.

Reuben Thomas (rrt) wrote :

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.

Rolf Leggewie (r0lf) wrote :

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".

Changed in upstart (Ubuntu Saucy):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers