Bug 62622 - /dev/vcsa* not owned by vcsa
Summary: /dev/vcsa* not owned by vcsa
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: dev   
(Show other bugs)
Version: 1.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Ben Levenson
Depends On:
Blocks: 61901
TreeView+ depends on / blocked
Reported: 2002-04-03 06:35 UTC by vvs
Modified: 2005-10-31 22:00 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-04-15 06:07:16 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 vvs 2002-04-03 06:35:43 UTC
Description of Problem:

/dev/vcsa* owned by root. This prevents cons.saver from working.

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


How Reproducible:


Steps to Reproduce:
1. Install dev-3.3-3 and look at /dev/vcsa* owner

Actual Results:

It's owned by root

Expected Results:

It should be owned by vcsa

Additional Information:

Comment 1 Nalin Dahyabhai 2002-04-05 08:17:53 UTC
The owner is set to 'vcsa' on my test machine here.  Are any errors printed when
you install this package (or if installed at install-time, in the install.log file)?

Comment 2 vvs 2002-04-05 11:55:06 UTC
Nope, no errors. I've rebuilt it from the src rpm and did an upgrade over an
existing dev. I didn't see any mention of user vcsa in the src, so I decided to
report it as a bug. Where this owner should come from? What part of MAKEDEV
changes it?

Comment 3 Nalin Dahyabhai 2002-04-05 17:53:22 UTC
The account should be created by the pre-install scriptlet in the dev package.

Comment 4 vvs 2002-04-08 05:42:22 UTC
Yes, it is. But what part of MAKEDEV changes the /dev/vcsa* owner?

Comment 5 Nalin Dahyabhai 2002-04-08 13:59:10 UTC
MAKEDEV does not change any ownerships automatically.  The owner of the device
ownership is set (or changed) when the dev package is installed (or upgraded).

Comment 6 vvs 2002-04-09 05:58:24 UTC
Of course. But let's put it the other way: when you build the binary rpm from
the sources, which part of that source rpm (MAKEDEV-3.3-3.src.rpm) is
responsible for changing the owner of /dev/vcsa* in that binary rpm?

Comment 7 Nalin Dahyabhai 2002-04-09 19:41:24 UTC
The files manifest in the .spec file specifies the owner of the device, and RPM
stores that information directly in the package.

Comment 8 vvs 2002-04-10 05:32:11 UTC
Yep, that's the point :-) So, where is it in the MAKEDEV.spec? I double-checked
it and the only reference to vcsa user is when it was created.

Comment 9 Nalin Dahyabhai 2002-04-10 16:19:17 UTC
MAKEDEV prints out the ownerships when it is run during the %install phase, and
the list is processed by RPM.  You can verify the result by running "rpm -qplv"
against the binary package.

I've just reinstalled using the latest tree and have verified that the
ownerships are set correctly.  I'm inclined to mark this as WORKSFORME because,
well, it works for me.

Comment 10 Nalin Dahyabhai 2002-04-10 16:40:49 UTC
Sanity check: you are using RPM to install the package, right?

Comment 11 vvs 2002-04-11 05:25:35 UTC
I've rebuilt it from SRPM myself and then installed produced binary RPM. Did you
do the same? I did rpm -qlpv on this RPM and all files in it are owned by root.
I don't understand how it could work for you. Could something in the build
environment affect the ownership of these files?

Comment 12 Nalin Dahyabhai 2002-04-11 14:30:03 UTC
If you are building the package as root, and the vcsa user does not exist on the
system when you build it, then I think the method used to generate the files
manifest might lose the ownership.  3.3-4 will use the same method when building
as the superuser as it does for non-privileged users, which should fix this.

Comment 13 vvs 2002-04-15 06:07:11 UTC
You were right, that was the reason. The new version works just fine. You can
close this bug now. Thank you for your patience :-)

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