Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Development (http://www.linux-archive.org/debian-development/)
-   -   Introduction of a "lock" group (http://www.linux-archive.org/debian-development/564457-introduction-lock-group.html)

Roger Leigh 08-15-2011 03:11 PM

Introduction of a "lock" group
 
Hi folks,

Fedora has moved to having /var/lock (now /run/lock) owned by
root:lock 0775 rather than root:root 01777. This has the advantage
of making a system directory writable only by root or setgid lock
programs, rather than the whole world. However, due to the
potential for privilege escalation¹² it may be desirable to adopt
what has been done subsequently in Fedora:
/var/lock root:root 0755
/var/lock/lockdev root:lock 0775
/var/lock/subsys root:root 0755

This mail is to discuss these issues:

1) Addition of a "lock" group as a system group

This is a trivial change but requires approval.

2) Alignment of /var/lock with Fedora

This will require patching of lockdev (should already be in git).
It would also require programs patching to use the new paths
if not using lockdev.

Are these any other downsides we need to consider? One issue is the
existence of badly broken programs³, which make stupid assumptions
about lockfiles.


¹http://lists.freedesktop.org/archives/systemd-devel/2011-April/001828.html
²https://bugzilla.redhat.com/show_bug.cgi?id=581884
³http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637856


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.

Andreas Barth 08-15-2011 03:31 PM

Introduction of a "lock" group
 
* Roger Leigh (rleigh@codelibre.net) [110815 17:12]:
> Are these any other downsides we need to consider? One issue is the
> existence of badly broken programs³, which make stupid assumptions
> about lockfiles.

This will break all existing programms on an partial upgrades. There
are three ways to deal with it:
1. Don't adjust permissions on existing systems
2. Add Breaks to all relevant programs
3. Adjust permissions on existing systems one release later


Andi


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110815153144.GA15003@mails.so.argh.org">http://lists.debian.org/20110815153144.GA15003@mails.so.argh.org

Iustin Pop 08-15-2011 04:03 PM

Introduction of a "lock" group
 
On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote:
> Hi folks,
>
> Fedora has moved to having /var/lock (now /run/lock) owned by
> root:lock 0775 rather than root:root 01777. This has the advantage
> of making a system directory writable only by root or setgid lock
> programs, rather than the whole world. However, due to the
> potential for privilege escalation¹² it may be desirable to adopt
> what has been done subsequently in Fedora:
> /var/lock root:root 0755
> /var/lock/lockdev root:lock 0775
> /var/lock/subsys root:root 0755

Hi,

If /var/lock won't be 1777 anymore, where should then applications store
application-specific lock files (e.g. synchronisation between daemons)
if they can't/won't run as setgid lock?

Is the intention that the init script creates a /var/lock/$NAME
directory, chgrp's it to the right GIDs and only then start the daemons?

thanks,
iustin

Roger Leigh 08-15-2011 04:31 PM

Introduction of a "lock" group
 
On Mon, Aug 15, 2011 at 06:03:59PM +0200, Iustin Pop wrote:
> On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote:
> > Hi folks,
> >
> > Fedora has moved to having /var/lock (now /run/lock) owned by
> > root:lock 0775 rather than root:root 01777. This has the advantage
> > of making a system directory writable only by root or setgid lock
> > programs, rather than the whole world. However, due to the
> > potential for privilege escalation¹² it may be desirable to adopt
> > what has been done subsequently in Fedora:
> > /var/lock root:root 0755
> > /var/lock/lockdev root:lock 0775
> > /var/lock/subsys root:root 0755
>
> If /var/lock won't be 1777 anymore, where should then applications store
> application-specific lock files (e.g. synchronisation between daemons)
> if they can't/won't run as setgid lock?
>
> Is the intention that the init script creates a /var/lock/$NAME
> directory, chgrp's it to the right GIDs and only then start the daemons?

I'll have to inspect what Fedora is doing more closely to give you
a definitive answer.

If you always start the daemon as root, it can continue to use
/var/lock without trouble if it does its file handling before changing
to a less privileged user. Creating a daemon-specific subdirectory is
also fine, though you could nowadays also use /run/<daemon> for daemon-
specific things, including locks. Or even /var/lib/<daemon> if they
should persist.

In some respects, /var/lock is a bit of an anachronism; /var/run
exists for pidfiles, and actual UUCP-style lockfiles are badly
broken--we should be moving to direct device locks. If it's a
daemon-specific lock, rather than one with system-wide effects
such as device locking, it probably doesn't belong under /var/lock.
If we eliminate device locking using lockfiles, what's left to go
under /var/lock? [I don't always agree with Lennart Poettering, but
his views on /var/lock and device lockfiles being obsolete are, I
think, entirely correct.]


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.

Colin Watson 08-15-2011 04:35 PM

Introduction of a "lock" group
 
On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote:
> Fedora has moved to having /var/lock (now /run/lock) owned by
> root:lock 0775 rather than root:root 01777. This has the advantage
> of making a system directory writable only by root or setgid lock
> programs, rather than the whole world. However, due to the
> potential for privilege escalation¹² it may be desirable to adopt
> what has been done subsequently in Fedora:
> /var/lock root:root 0755
> /var/lock/lockdev root:lock 0775
> /var/lock/subsys root:root 0755
>
> This mail is to discuss these issues:
>
> 1) Addition of a "lock" group as a system group
>
> This is a trivial change but requires approval.

Would such a system group need to be statically allocated, or could it
be dynamically allocated? (Generally the latter is better if possible,
of course - I haven't had to add a global static group for years, and I
like it that way - but one might wish to consider things like bind
mounts of /run/lock into chroots, which would no longer be
NSS-agnostic.)

> Are these any other downsides we need to consider? One issue is the
> existence of badly broken programs³, which make stupid assumptions
> about lockfiles.

What about programs that need to write lock files which are already
setgid something else? I don't have an example off the top of my head,
but it would surprise me if there were none of these.

--
Colin Watson [cjwatson@debian.org]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110815163554.GA3610@riva.dynamic.greenend.org.uk ">http://lists.debian.org/20110815163554.GA3610@riva.dynamic.greenend.org.uk

Roger Leigh 08-15-2011 05:00 PM

Introduction of a "lock" group
 
On Mon, Aug 15, 2011 at 05:35:54PM +0100, Colin Watson wrote:
> On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote:
> > Fedora has moved to having /var/lock (now /run/lock) owned by
> > root:lock 0775 rather than root:root 01777. This has the advantage
> > of making a system directory writable only by root or setgid lock
> > programs, rather than the whole world. However, due to the
> > potential for privilege escalation¹² it may be desirable to adopt
> > what has been done subsequently in Fedora:
> > /var/lock root:root 0755
> > /var/lock/lockdev root:lock 0775
> > /var/lock/subsys root:root 0755
> >
> > This mail is to discuss these issues:
> >
> > 1) Addition of a "lock" group as a system group
> >
> > This is a trivial change but requires approval.
>
> Would such a system group need to be statically allocated, or could it
> be dynamically allocated? (Generally the latter is better if possible,
> of course - I haven't had to add a global static group for years, and I
> like it that way - but one might wish to consider things like bind
> mounts of /run/lock into chroots, which would no longer be
> NSS-agnostic.)

I was initially thinking that static would be the best approach.
But if the general consensus is that /var/lock/lockdev etc. aren't
going to be around in the long term, then dynamic would be better--
we can then switch lockdev and other UUCP-style lock users to
direct locking and remove it. There is compatibility with
ancient UUCP software to consider though, but how important is that?
They have had years to switch to using liblockdev.

> > Are these any other downsides we need to consider? One issue is the
> > existence of badly broken programs³, which make stupid assumptions
> > about lockfiles.
>
> What about programs that need to write lock files which are already
> setgid something else? I don't have an example off the top of my head,
> but it would surprise me if there were none of these.

IIRC Fedora have a setgid lock locking helper for this, which lockdev
uses internally. I'd need to check the details on a Fedora VM. IIRC
it checks if you have write perms on the device being locked, and so
individual programs don't need to be setgid lock unless they are not
using liblockdev.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.

Iustin Pop 08-15-2011 05:36 PM

Introduction of a "lock" group
 
On Mon, Aug 15, 2011 at 06:00:50PM +0100, Roger Leigh wrote:
> On Mon, Aug 15, 2011 at 05:35:54PM +0100, Colin Watson wrote:
> > On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote:
> > > Are these any other downsides we need to consider? One issue is the
> > > existence of badly broken programs³, which make stupid assumptions
> > > about lockfiles.
> >
> > What about programs that need to write lock files which are already
> > setgid something else? I don't have an example off the top of my head,
> > but it would surprise me if there were none of these.
>
> IIRC Fedora have a setgid lock locking helper for this, which lockdev
> uses internally. I'd need to check the details on a Fedora VM. IIRC
> it checks if you have write perms on the device being locked, and so
> individual programs don't need to be setgid lock unless they are not
> using liblockdev.

The use of an external helper means this is significantly slower than an
open(…, O_CREAT) + flock(). While this works for some workloads, it
doesn't for all.

As my other question was: /var/lock (or /run/lock) was a good solution
for transient, "cheap" locks for coordination between some cooperative
programs. It would be ideal if we have a recipe for this after the
permissions change.

thanks,
iustin

Roger Leigh 08-16-2011 03:25 PM

Introduction of a "lock" group
 
On Mon, Aug 15, 2011 at 06:03:59PM +0200, Iustin Pop wrote:
> On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote:
> > Hi folks,
> >
> > Fedora has moved to having /var/lock (now /run/lock) owned by
> > root:lock 0775 rather than root:root 01777. This has the advantage
> > of making a system directory writable only by root or setgid lock
> > programs, rather than the whole world. However, due to the
> > potential for privilege escalation¹² it may be desirable to adopt
> > what has been done subsequently in Fedora:
> > /var/lock root:root 0755
> > /var/lock/lockdev root:lock 0775
> > /var/lock/subsys root:root 0755
>
> If /var/lock won't be 1777 anymore, where should then applications store
> application-specific lock files (e.g. synchronisation between daemons)
> if they can't/won't run as setgid lock?
>
> Is the intention that the init script creates a /var/lock/$NAME
> directory, chgrp's it to the right GIDs and only then start the daemons?

This is how Fedora currently does it:

Packages store their data in /var/lock/subsys/$package
and this is created using /etc/tmpfiles.d. Packages
can provide /etc/tmpfiles.d/$package and have a dpkg
trigger or script e.g. update-tmpfiles create the missing
directories. They would also be created at boot time.
The tmpfiles.d file format specifies the name, ownership
and permissions, which would allow daemon-specific
ownership of their directories.

tmpfiles.d comes from systemd, but we could adopt the concept
without systemd being involved. If we didn't adopt tmpfiles.d,
it would be the responsibility of the init script to create
the necessary directories.

I'm not entirely sure of the rationale for using
/var/lock/subsys/$package rather than just using
/var/lock/$package, which seems rather redundant IMO.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.

Roger Leigh 08-16-2011 03:30 PM

Introduction of a "lock" group
 
On Mon, Aug 15, 2011 at 07:36:26PM +0200, Iustin Pop wrote:
> On Mon, Aug 15, 2011 at 06:00:50PM +0100, Roger Leigh wrote:
> > On Mon, Aug 15, 2011 at 05:35:54PM +0100, Colin Watson wrote:
> > > On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote:
> > > > Are these any other downsides we need to consider? One issue is the
> > > > existence of badly broken programs³, which make stupid assumptions
> > > > about lockfiles.
> > >
> > > What about programs that need to write lock files which are already
> > > setgid something else? I don't have an example off the top of my head,
> > > but it would surprise me if there were none of these.
> >
> > IIRC Fedora have a setgid lock locking helper for this, which lockdev
> > uses internally. I'd need to check the details on a Fedora VM. IIRC
> > it checks if you have write perms on the device being locked, and so
> > individual programs don't need to be setgid lock unless they are not
> > using liblockdev.
>
> The use of an external helper means this is significantly slower than an
> open(…, O_CREAT) + flock(). While this works for some workloads, it
> doesn't for all.

This helper is basically restricted to device locking, in particular
serial devices (minicom, uucp, wvdial etc.). I can't off the top of
my head think of a scenario where this would cause problems. It's
also basically a temporary solution until these programs can be
patched to use lockdev, and/or for lockdev to support proper device
locking with fcntl.

> As my other question was: /var/lock (or /run/lock) was a good solution
> for transient, "cheap" locks for coordination between some cooperative
> programs. It would be ideal if we have a recipe for this after the
> permissions change.

This should hopefully have been addressed in my other reply WRT
tmpfiles.d, which permits this providing you have a directory
writable by the user/group in question. Access for normal users
is however no longer possible--they would need to use somewhere
they have write access, e.g. /tmp.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.

Peter Samuelson 08-16-2011 04:19 PM

Introduction of a "lock" group
 
[Roger Leigh]
> tmpfiles.d comes from systemd, but we could adopt the concept
> without systemd being involved. If we didn't adopt tmpfiles.d,
> it would be the responsibility of the init script to create
> the necessary directories.

Makes sense that tmpfiles.d comes from systemd, if he's trying to get
away from shell scripts. But for those who think it's annoying to have
to put 3 separate steps in your init script 'start' section (mkdir -p,
chown, chmod), I'd like to point out that you may as well just use
install -d, and do it all in one step.

Not to say we _can't_ adopt the tmpfiles.d approach, just that doing
this sort of thing inside your init script need not be painful.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110816161905.GB7582@p12n.org">http://lists.debian.org/20110816161905.GB7582@p12n.org


All times are GMT. The time now is 08:02 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.