Bug 127034 - fc2 is effectively single-user
Summary: fc2 is effectively single-user
Alias: None
Product: Fedora
Classification: Fedora
Component: pam   
(Show other bugs)
Version: 2
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2004-06-30 20:13 UTC by Sam Steingold
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-30 23:17:38 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Sam Steingold 2004-06-30 20:13:53 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040614 Firefox/0.8

Description of problem:
I want to share a computer between two people: A and B.
runlevel is 3, both login on a console, start one's own 
X server ("startx -- :0" and "startx -- :1"), and take
turns using the computer, switching between their X servers
with Ctrl-Alt-F7 and Ctrl-Alt-F8.  Worked JUST FINE originally.

Unfortunately, starting somewhere at RH8, 
this stopped  working perfectly:
the first user to login gets all audio devices assigned to him
(as in "chown A.root /dev/audio...; chmod u+re,go-rwx !$")
so the second user B cannot listen to music and play movies.

I solved this problem by creating a group "sound", 
adding both A and B to "sound", and doing
$ chgrp soung /dev/audio...; chmod g+rw !$
this had to be done several times, after each boot and upgrade, 
but it was tolerable (though unfortunate!)

With FC2, this system was extended to X.
The second user to login can no longer start X!
The "FC2" banner appears, the cursor becomes "x", 
but no "small icons" ever appear 
(and the server can be killed with Ctrl-Alt-Backspace 
even though I set DonTZap in /etc/X11/XF86Config).
This happens even after the A stops his X server - 
B still cannot start his own X session.

Therefore, now FC2 is effectively single-user:
A and B cannot share the same computer each having his own X session.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.set runlevel to 3
2.A logs in on a console, types "startx"
3.B logs in on a console, types "startx -- :1"

Actual Results:  A gets a normal gnome desktop
B gets an "FC2" splash screen which just sits there forever
A can listen to music and play movies.
B cannot.
when a CD is put in, it is mounted by A, not by B, 
even if A is away and B is in front of the computer.

Expected Results:  
B should also get his normal gnome desktop, like in FC1.
B should also be able to listen to music and play movies.
when A is away and B is in front of the computer, 
CDs should be mounted by B, not by A.

Additional info:

Please do not consider this X-specific.
Yes, I will try running at runlevel 5 and start 2 gdms
(by editing the [servers] section in /etc/X11/gdm/gdm.conf).

Even if it works, this does not resolve the original 
problem which I worked around with the "sound" group.

This is why I set severity to "security": apparently, you
chose this model (making the "first user to login" the owner
of the sound devices) for security reasons (the alernative
being to make the devices world writable).
Please consider making them group-writable, for the group
of the human users who have physical access to this computer.

More information:

Comment 1 Mike A. Harris 2004-06-30 21:54:00 UTC
I don't see any actual X.Org X11 bug mentioned anywhere in the
above report.

When filing bug reports, please file one single bug per report,
and file it against the correct component.  If you're not sure
what the correct component is for a particular bug, or if a bug
doesn't really fit into a component, but is instead a general
issue or a feature request for an addition to the distribution,
use the "distribution" component.

Closing invalid report as 'NOTABUG', feel free to re-file
individual bug reports against correct components as described
above if desired.

Comment 2 Alan Cox 2004-06-30 22:00:04 UTC
Moved to pam just for neatness (/etc/security/console.perms being the
relevant policy and pam owned)

Comment 3 Sam Steingold 2004-06-30 22:23:08 UTC
Re-filing under "distribution":
Some part might just boil down to the correct settings in
/etc/security/console.perms (thanks Alan!), but 
the cdrom mounting probably does not, although
I have no idea which component is responsible for automounting.

Comment 4 Alan Cox 2004-06-30 23:17:38 UTC
magicdev does automounting, based on the permissions on the CD-ROM
drive and the configuration of the mount table.

If you want to debate policy issues about the console management and
ownership in Fedora you should probably do it on the fedora-devel
mailing list.

Note You need to log in before you can comment on or make changes to this bug.