This is nothing new.  Mandriva stopped hard-coding system users and UIDs a long time ago (partially because there's too many of them I think).  Fresh installations aren't guaranteed to give you the same UIDs (even for regular users), so that's the sysadmin's responsibility.  It's not that difficult to chown -R apache.apache /var/www/html and any other directory that has files owned by apache if you're restoring from backups or bringing over old hard drives.

Long-term maybe we could discuss standardizing system user UIDs somehow, as well as moving the regular user UIDs up to 1000 like Fedora did, but that's a discussion for another time.

>It's not that difficult to
chown -R apache.apache /var/www/html and any other directory that has files
owned by apache if you're restoring from backups or bringing over old hard
drives.

That's not quite true.  Firstly, it's exactly those files used by apache and *not* controlled by the rpm that have to be modified, and there's no easy way to identify them all.  Secondly, if apache is serving files from filesystems owned by other systems on which the UID/GID is different, it's impossible; apache on one system or the other will break.

Lastly, Mercurial regards a change in ownership as an underlying source change.  Since shared network access to Mercurial repositories is done through HTTP (almost always apache), having to change these permissions means turning on "modified" status for every file in the repository, necessitating bogus commits to get things back to normal.

I knew that there was some possibility of UID/GID change for reasonably self-contained packages like gdm, but I don't ever remember them changing for packages which involve the use of user-provided files.

I'd recommend that at least apache be locked down to a fixed UID/GID, and I really don't see the problem in using a central registry for this stuff.  I assume that the rpms all use some common routine which is scanning /etc/passwd and /etc/group for the next available value, and that would be the perfect point to insert a call to the registry instead, or even embed the registry in that routine.

(In reply to comment #2)
> >It's not that difficult to
> chown -R apache.apache /var/www/html and any other directory that has files
> owned by apache if you're restoring from backups or bringing over old hard
> drives.
> 
> That's not quite true.  Firstly, it's exactly those files used by apache and
> *not* controlled by the rpm that have to be modified, and there's no easy way
> to identify them all.  Secondly, if apache is serving files from filesystems
> owned by other systems on which the UID/GID is different, it's impossible;
> apache on one system or the other will break.

The files apache needs access to should be in known locations, and -R means recursive, so you don't have to "identify them all."

If Apache is serving files off an NFSv3-mounted filesystem, then yes the UIDs would have to be the same, but again, that's an unusual deal and the administrator's responsibility to make it match.

> Lastly, Mercurial regards a change in ownership as an underlying source change.
>  Since shared network access to Mercurial repositories is done through HTTP
> (almost always apache), having to change these permissions means turning on
> "modified" status for every file in the repository, necessitating bogus commits
> to get things back to normal.

That's a bit strange.  The only thing changing the UIDs changes is the ctime, but restoring files from a backup will do that anyway.  If that's the case, probably the best thing would be to uninstall apache (and anything else using that account), add the account manually, then reinstall apache.

> I'd recommend that at least apache be locked down to a fixed UID/GID, and I
> really don't see the problem in using a central registry for this stuff.  I
> assume that the rpms all use some common routine which is scanning /etc/passwd
> and /etc/group for the next available value, and that would be the perfect
> point to insert a call to the registry instead, or even embed the registry in
> that routine.

Sure, but again, that's a major change that's not going to happen immediately.

>The files apache needs access to should be in known locations, and -R means
recursive, so you don't have to "identify them all."

I'm aware of that, but again, I'm not talking about the official files controlled by the rpm itself, e. g. runtime directories used by apache itself.  Those can be identified via the rpm, and are probably being created by it during install with the new UID/GID.

>If Apache is serving files off an NFSv3-mounted filesystem, then yes the UIDs
would have to be the same, but again, that's an unusual deal and the
administrator's responsibility to make it match.

I don't find anything unusual about multiple instances of apache on multiple system images all serving files from the same NFS fileserver.  And that's exactly the type of production setup we shouldn't want to break.  And, as I pointed out, if they don't all use the same UID/GID because the system images have been installed at different times, it will break.

>That's a bit strange.  The only thing changing the UIDs changes is the ctime,
but restoring files from a backup will do that anyway.

I'm not sure whether Mercurial records data from the i-node, or just records the ctime, but restoring a Mercurial repository from a backup won't cause the effect I mentioned (assuming the backup was done retaining ownership and timestampts) because the embedded Mercurial metadata will match the restored repository.

>Sure, but again, that's a major change that's not going to happen immediately.

I don't see what's so major about a 2-line change in the common ID assignment routine that gives a specific UID/GID to apache (1 line) and makes sure that it doesn't give that UID/GID to anyone else (1 line).  I agree that the full-blown implementation can wait for Mageia 3.

While it would be easy to have /usr/share/rpm-helper/add-user
use a specific uid for apache, how do you see preventing
other system packages from using that uid before apache
is installed?

As far as I know, the useradd command does not have a
"don't use this uid" option.

CC: (none) => davidwhodgins

>As far as I know, the useradd command does not have a
"don't use this uid" option.

It doesn't need one.  I'm talking about a temporary kludge to whatever the rpms use, be it add-user or useradd, to internally recognize "apache" and assign a specific UID/GID, and *not* give that UID/GI to anything else.  Callers don't have to do anything to trigger this.

For mga 3 we can look at replacing the kludge with a formal list of assigned system UID/GID pairs.

perhaps we can add something through systemd, that checks directories the daemon uses for user ids matching the user id of the deamon. and gives a warning on start.

after a new install, for local storage it could be done automagically, but i'd rather not.

for networked storage, it's too dangerous to change it. i would advice to use nfsv4 instead and map the user names.

that said, nothing else really can be done except maybe give a warning.

CC: (none) => alien

Same problem with backkuppc: backed-up files are owned by the user "backuppc" with a uid/gid value that must not change. In case a formal list of assigned uid/gid pairs is created, please include the user "backuppc".

At present, I use the workaround to manually - by script - define the user backuppc before installing the backuppc package, using uid/gid values in the normally unused slot below 500. That could be formalized by having a zone of id values that are reserved for user-determined attribution - I agree, a formally established list (plus place for spares) would be better.

CC: (none) => juergen.harms

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

The reply should come from the reporter, anticipating since this is evident: the problem is a conceptual issue that has not been addressed in Mageia 2. I wonder whether this problem should not be added to the list of Mageia 3 design items.

(In reply to comment #10)
> The reply should come from the reporter, anticipating since this is evident:
> the problem is a conceptual issue that has not been addressed in Mageia 2. I
> wonder whether this problem should not be added to the list of Mageia 3 design
> items.

Yes, that would be the appropriate place to address it.

Whiteboard: MGA2TOO => (none)

This is not something that will be changed in already released versions.

Whiteboard: MGA2TOO => (none)

Ah, I didn't notice that you had removed MGA2TOO; I thought I had just forgotten to add it.  You're right, of course.

Hi Frank,

I imagine you saw this on the mageia-dev list, but just in case you missed it, Juergen was referring to the features proposals for Mageia 3.  If you want to make sure this isn't forgotten, it would be a good idea to propose this feature yourself.  I think feature proposals are due by the end of this week.  Basically it just consists of making a wiki page.  More info is here:
https://wiki.mageia.org/en/Features_policy

Maybe a solution to this could be (at least an option) to refer to accounts in the system range by name instead of uid or gid ?
Don't know the downside of this (security-wise), but it could be a white list of system range accounts, or excluding a black list of such accounts.

Could that work ?
And relatively easily implemented ?

CC: (none) => andre999mga

The problem isn't NFS.  Practically all simple NFS home setups have gone to NFSv4, and it will use the idmapd service to transparently map ids by name to the correct local UID.

The problem is systems which export files through means other than NFS, e. g. Apache/HTTP, and files that are separate from the root partition but are owned by system software, e. g. database files.  These are very common situations among simple home-user setups, and anyone who follows the best-practice of decoupling data from the system partition and doing periodic fresh installs is going to get bitten by this.

Yes, there are ways to remediate this.  You can require people to chown all their data files, but this isn't as automatic as you'd like if there's overlap between the reassigned UIDs.  If Apache goes from 492 to 484 and xyz gors from 425 to 492, a blanket chown of 492 to 484 hits xyz's files as well.

The point is, we shouldn't be putting home and small business users in this position without some really good reason, and I don't see a really good reason here.  What is the upside of doing this ?  What advantage offsets the problems we're causing here ?

Assigning to all packagers collectively, but it's a big change that should probably be adressed via a feature proposal for next Mageia release, as has been mentioned in the comments above already.

Assignee: bugsquad => pkg-bugs
Source RPM: apache => (none)
Severity: critical => enhancement

Ping ?

I'm going to close this bug as wontfix.

I'm well aware of the problem, but fixing it properly is beyond the scope of
what Mageia can do.

One fix would be to identify every package we have that adds users and or
groups, and reserve ids for each and every one of them in a table used by
the user and group add tools, but that would run into problems with any
package installed that comes from sources other then Mageia that adds
users or groups. That would also severely complicate upgrading from a
release that doesn't use such a table, to one that does. I have no idea
how many packages we have that add users and or groups, or if there are
enough ids available to do this.

Fixing it properly would requires the co-operation of every developer of
linux packages that need users or groups added, with some sort of central
assigner of id and group numbers.

It would also restrict the ability of user ids to share group ids for system
admins that want that, in the case where some other system admins may not
want the ids to share a group. Forcing one preferred solution on all system
admins is not the linux way.

Resolution: (none) => WONTFIX
Status: NEW => RESOLVED

It doesn't have to be only the listed uid/gid for an application or the application is not installed.
It need only be the preferred uid/gid, with others being selected (much as now) if the preferred values aren't available.
In the longer term, most of the preferred uid/gid for a given application would be available.

The logic is simple :
Whenever an application requests a uid and/or gid :
Are the requested uid/gid already assigned for the application
 _or_ is the application in the list _and_ are the uid/gid available ?
. . If so, use them.
else use some uid/gid which isn't in the list.

Note that this doesn't stop sysadmins from choosing uid/gid they want, it is only necessary to define the preferred uid/gid before installing the application, as they would have to do now.

So very easy to implement, but the transition will occur only for clean installs or uninstallation/reinstallation of affected packages.

I suggest that "resolved/wontfix" be reverted.

I agree with Dave, and the fact that nothing has happened on this in almost seven years since this bug was filed ought to say something.  I don't disagree that having a bit more stability with certain UIDs/GIDs would be nice, but we could go on arguing about it in this bug for another seven years and that's not going to accomplish something.

As has been mentioned multiple times already in this bug, the only way this will be resolved is if someone makes a *concrete* proposal of how it will be addressed and identifies the necessary resources to help implement it, proposes it as a feature of a future Mageia release, gets that to be approved, and likely, actually implements it.

I think the complications mentioned in comment 19 are overstated, but appreciate the points raised in comment 21.

The approach raised in comment 20 should work, as long as the applications required to be modified are identified, and the steps outlined in comment 21 are followed.

Personally I don't see how leaving the bug open is problematic, but closing it doesn't prevent a solution from being developped.

Maybe Frank (the reporter) can suggest a list of applications with corresponding uid/gid ?