How to make device permissions stick?

Peter Sutter

16 Jan 2006 16 Jan '06

10:28

I have a SuSE V9.2 Linux system with a dvd burner on /dev/hda. There is a web page based on a php script that allows users to specify directories to upload and burn to the dvd. To do this, wwwrun needs to have r/w access to /dev/hda. So I changed the permissions with chmod 666 /dev/hda. A ls -ls /dev/hda shows brw-rw-rw- 1 root disk 3, 0 Oct 2 2004 /dev/hda After the system is re-booted, the device permissions are back to brw------- 1 root disk 3, 0 Oct 2 2004 /dev/hda I stuck the line /dev/hda root:disk 666 into /etc/permissions, in the hope that this will fix the problem. Unfortunately this does not work either, i.e. after a re-boot, the permissions are back to brw------- 1 root disk 3, 0 Oct 2 2004 /dev/hda Running SuSEconfig --module permissions fixes the problem, until the next boot. How is this done correctly? Which script on startup resets the device permission? Thanks for your help Peter

Show replies by date

Carlos E. R.

16 Jan 16 Jan

12:21

New subject: [SLE] How to make device permissions stick?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-01-16 at 18:28 +0800, Peter Sutter wrote:

...

I stuck the line /dev/hda root:disk 666 into /etc/permissions, in the hope that this will fix the problem. Unfortunately this does not work either, i.e. after a re-boot, the permissions are back to brw------- 1 root disk 3, 0 Oct 2 2004 /dev/hda

Running SuSEconfig --module permissions fixes the problem, until the next boot.

Perhaps '/etc/logindevperm', but that is at login time. It could be udev, but I don't know if 9.2 uses it. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDy4/EtTMYHG2NR9URAuK3AJ0QefrpACJ6FF3NncdYp0MSjDf0bwCeJ1B/ BrPidxyuL36tGMVa7FV3axo= =/Rr3 -----END PGP SIGNATURE-----

Sunny

14:44

New subject: [SLE] How to make device permissions stick?

On 1/16/06, Peter Sutter wrote:

...

I have a SuSE V9.2 Linux system with a dvd burner on /dev/hda. There is a web page based on a php script that allows users to specify directories to upload and burn to the dvd. To do this, wwwrun needs to have r/w access to /dev/hda. So I changed the permissions with chmod 666 /dev/hda. A ls -ls /dev/hda shows brw-rw-rw- 1 root disk 3, 0 Oct 2 2004 /dev/hda After the system is re-booted, the device permissions are back to brw------- 1 root disk 3, 0 Oct 2 2004 /dev/hda

I stuck the line /dev/hda root:disk 666 into /etc/permissions, in the hope that this will fix the problem. Unfortunately this does not work either, i.e. after a re-boot, the permissions are back to brw------- 1 root disk 3, 0 Oct 2 2004 /dev/hda

Running SuSEconfig --module permissions fixes the problem, until the next boot.

How is this done correctly? Which script on startup resets the device permission?

Thanks for your help

Peter

The easiest way I can think of is to use k3bsetup utility. There you have to select "Use burning group". This will set up the right permissions for the specified group (usualy this is the group "burning", but you can change it to "disk" if you want wwwrun to run as a member of the "disk" group). Or, you may set the wwwrun to run as a user, who is member of the "burning" group. Cheers -- -- Svetoslav Milenov (Sunny)

Peter Sutter

17 Jan 17 Jan

00:42

New subject: [SLE] How to make device permissions stick?

On Monday 16 January 2006 22:44, Sunny wrote:

...

On 1/16/06, Peter Sutter wrote:

...
I have a SuSE V9.2 Linux system with a dvd burner on /dev/hda. There is a web page based on a php script that allows users to specify directories to upload and burn to the dvd. To do this, wwwrun needs to have r/w access to /dev/hda. So I changed the permissions with chmod 666 /dev/hda. A ls -ls /dev/hda shows brw-rw-rw- 1 root disk 3, 0 Oct 2 2004 /dev/hda After the system is re-booted, the device permissions are back to brw------- 1 root disk 3, 0 Oct 2 2004 /dev/hda

I stuck the line /dev/hda root:disk 666 into /etc/permissions, in the hope that this will fix the problem. Unfortunately this does not work either, i.e. after a re-boot, the permissions are back to brw------- 1 root disk 3, 0 Oct 2 2004 /dev/hda

Running SuSEconfig --module permissions fixes the problem, until the next boot.

How is this done correctly? Which script on startup resets the device permission?

Thanks for your help

Peter

The easiest way I can think of is to use k3bsetup utility. There you have to select "Use burning group". This will set up the right permissions for the specified group (usualy this is the group "burning", but you can change it to "disk" if you want wwwrun to run as a member of the "disk" group). Or, you may set the wwwrun to run as a user, who is member of the "burning" group.

Cheers

-- -- Svetoslav Milenov (Sunny)

Thanks, Sunny The burning runs under wwwrun. Assigning a group does not help, because the file re-sets to brw------- 1 root disk 3, 0 Oct 2, 2004 /dev/hda which does not give write access to the group, only to the owner. Peter

Sunny

15:28

New subject: [SLE] How to make device permissions stick?

On 1/16/06, Peter Sutter wrote:

...

Thanks, Sunny

The burning runs under wwwrun. Assigning a group does not help, because the file re-sets to brw------- 1 root disk 3, 0 Oct 2, 2004 /dev/hda which does not give write access to the group, only to the owner.

Peter

Hi Peter, from your answer I did not understand: Did you run k3bsetup program? Did you enabled "Using a burning group"? This should change the device permission to brw-rw--- for the group given in the setup. Then just add wwwrun user to this group. -- -- Svetoslav Milenov (Sunny)

Peter Sutter

18 Jan 18 Jan

02:04

New subject: [SLE] What is so special on /dev/hda? was how to make device permissions stick?

On Tuesday 17 January 2006 23:28, Sunny wrote:

...

On 1/16/06, Peter Sutter wrote:

...
Thanks, Sunny

The burning runs under wwwrun. Assigning a group does not help, because the file re-sets to brw------- 1 root disk 3, 0 Oct 2, 2004 /dev/hda which does not give write access to the group, only to the owner.

Peter

Hi Peter, from your answer I did not understand:

Did you run k3bsetup program? Did you enabled "Using a burning group"? This should change the device permission to brw-rw--- for the group given in the setup. Then just add wwwrun user to this group.

-- -- Svetoslav Milenov (Sunny) Thanks Sunny,

The machine the apache web server is running on does not have a graphical user interface. It is a server, nobody logs on to it interactively, except the system administrator fromtime to time. There is no kde or k3bsetup. The web page prompts for a directory, the files in this directory are then uploaded to the server and then burned to dvd. The image is created with mkisofs, for the burning of the image to dvd growisofs is used. To burn the dvd, growisofs needs physical access to the dvd burner, which is /dev/hda, and the permissions of /dev/hda change from 666 root:disks to 600 root:disks after a crash. We have a very unreliable power supply in the area with frequent power cuts and one of these older UPS with no interface to control it. So the system often crashes because of no power. When the system restarts when the power returns, /dev/hda has always a permission of 600 with owner root:disks, which is not enough for wwwrun:root to access the device. Something in the startup sets the permission back to 600 root:disks. Running SuSEconfig manually after a crash fixes the problem. If I know which script changes the permissions back to 600 root:disks, I could change it there, without having to run SuSEconfig manually. The strange thing is, that other devices keep their settings, it seems it is just the IDE drives /dev/hda that keeps changing, SATA and USB drives /dev/sda, /dev/sdb keep their settings after a re-boot. The boot/root partitions are on a SATA drive /dev/sda. Peter

Silviu Marin-Caea

07:23

New subject: [SLE] What is so special on /dev/hda? was how to make device permissions stick?

On Wednesday 18 January 2006 04:04, Peter Sutter wrote:

...

Something in the startup sets the permission back to 600 root:disks.

I have already aswered you, do you read your threads on the list? Device access is managed by resmgr. rpm -qi resmgr rpm -ql resmgr

Peter Sutter

10:58

New subject: [SLE] What is so special on /dev/hda? was how to make device permissions stick?

On Wednesday 18 January 2006 15:23, Silviu Marin-Caea wrote:

...

On Wednesday 18 January 2006 04:04, Peter Sutter wrote:

...
Something in the startup sets the permission back to 600 root:disks.

I have already aswered you, do you read your threads on the list?

Device access is managed by resmgr.

rpm -qi resmgr rpm -ql resmgr

Thanks Silviu. I followed your advise, but to no avail. SYNOPSIS resmgr [-s socket] [-u user] [-t] command ... Checking for running resmgr: # rcresmgr status Checking for resource manager: running OK, resmgr appears to be running. This is however all what I get # resmgr help resmgr: symbol lookup error: resmgr: undefined symbol: rsm_connect_to # resmgr list resmgr: symbol lookup error: resmgr: undefined symbol: rsm_connect_to What is needed to get resmgr going? Peter

Silviu Marin-Caea

11:25

New subject: [SLE] What is so special on /dev/hda? was how to make device permissions stick?

On Wednesday 18 January 2006 12:58, Peter Sutter wrote:

...

I followed your advise, but to no avail.

resmgr is running by default, you don't have to install it, just configure. /etc/init.d/resmgr status Checking for resource manager: running

Patrick Shanahan

13:30

New subject: [SLE] What is so special on /dev/hda? was how to make device permissions stick?

* Silviu Marin-Caea [01-18-06 06:25]:

...

On Wednesday 18 January 2006 12:58, Peter Sutter wrote:

...
I followed your advise, but to no avail.

resmgr is running by default, you don't have to install it, just configure.

/etc/init.d/resmgr status Checking for resource manager: running

normally, *system* configuration files are under /etc. Read 'man resmgr', then edit /etc/resmgr.conf. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2

Randall R Schulz

13:58

New subject: [SLE] What is so special on /dev/hda? was how to make device permissions stick?

Peter, On Wednesday 18 January 2006 02:58, Peter Sutter wrote:

...

...

Checking for running resmgr: # rcresmgr status Checking for resource manager: running

OK, resmgr appears to be running. This is however all what I get # resmgr help resmgr: symbol lookup error: resmgr: undefined symbol: rsm_connect_to

# resmgr list resmgr: symbol lookup error: resmgr: undefined symbol: rsm_connect_to

There appears to be a broken dependency. What output is produced by: % rpm -V resmgr

...

... Peter

Randall Schulz

Peter Sutter

14:45

New subject: [SLE] What is so special on /dev/hda? was how to make device permissions stick?

On Wednesday 18 January 2006 21:58, Randall R Schulz wrote:

...

Peter,

On Wednesday 18 January 2006 02:58, Peter Sutter wrote:

...
...

Checking for running resmgr: # rcresmgr status Checking for resource manager: running

OK, resmgr appears to be running. This is however all what I get # resmgr help resmgr: symbol lookup error: resmgr: undefined symbol: rsm_connect_to

# resmgr list resmgr: symbol lookup error: resmgr: undefined symbol: rsm_connect_to

There appears to be a broken dependency. What output is produced by:

% rpm -V resmgr

...
... Peter

Randall Schulz

Thanks Randall, rpm -v resmgr reported .......T c /etc/resmgr.conf which I interpret as all OK. I removed resmgr, installed it again and then run an online update. This seems to have fixed the problem, at least partially, in that I get a meaningful response now. So it appears that resmgr was broken. # resmgr list status code 200 server message follows: no devices available resmgr seems to dislike ssh connections. So I may have to physically visit the system to test it out further. I tried this on a test system here, I get access to resmgr when logged in on a console or via kde, but not via ssh. btw, would you know where I can find a description of the resmgr status codes? Thanks again Peter

Randall R Schulz

16:18

New subject: [SLE] What is so special on /dev/hda? was how to make device permissions stick?

Peter, On Wednesday 18 January 2006 06:45, Peter Sutter wrote:

...

...

Thanks Randall,

rpm -v resmgr reported .......T c /etc/resmgr.conf which I interpret as all OK.

I don't know why. Here's an excerpt from the man page you could have read to avoid guessing: % man rpm ... The format of the output is a string of 8 characters, a possible attribute marker: c %config configuration file. d %doc documentation file. g %ghost file (i.e. the file contents are not included in the package payload). l %license license file. r %readme readme file. from the package header, followed by the file name. Each of the 8 characters denotes the result of a comparison of attribute(s) of the file to the value of those attribute(s) recorded in the database. A single "." (period) means the test passed, while a single "?" (question mark) indicates the test could not be performed (e.g. file permissions prevent reading). Otherwise, the (mnemonically emBoldened) character denotes failure of the corresponding --verify test: S file Size differs M Mode differs (includes permissions and file type) 5 MD5 sum differs D Device major/minor number mis-match L readLink(2) path mis-match U User ownership differs G Group ownership differs T mTime differs ... The output you got means that /etc/resmgr.conf was touched (its modification time changed), though its content was not.

...

I removed resmgr, installed it again and then run an online update. This seems to have fixed the problem, at least partially, in that I get a meaningful response now. So it appears that resmgr was broken.

The diagnostic you were getting from the RPM verification was not about a config file, so whatever the problem, it was not in the resmgr package's files themselves, but if the reinstallation fixed the problem, then great.

...

# resmgr list status code 200 server message follows: no devices available

resmgr seems to dislike ssh connections.

% man pam_resmgr % resmgr list r--- /dev/console rw-- /dev/adsp rw-- /dev/audio rw-- /dev/dsp rw-- /dev/mixer rw-- /dev/snd/controlC0 rw-- /dev/snd/pcmC0D0c rw-- /dev/snd/pcmC0D0p rw-- /dev/snd/pcmC0D1p rw-- /dev/snd/pcmC0D2p rw-- /dev/snd/pcmC0D3p rw-- /dev/midi rw-- /dev/snd/midiC0D0 rw-- /dev/snd/seq rw-- /dev/snd/timer rw-- /dev/input/event2 rw-- usb:bus=3,dev=2 rw-- /dev/hdc rw-- /dev/hda rw-- /dev/fd0

...

So I may have to physically visit the system to test it out further. I tried this on a test system here, I get access to resmgr when logged in on a console or via kde, but not via ssh.

The "list" verb does not require root privilege, by the way.

...

btw, would you know where I can find a description of the resmgr status codes?

% man resmgrd

...

... Peter

I hope you see the pattern in my answers. Perhaps you'd be willing to dispense with the "Reply-To" header in your posts to this list? Randall Schulz

Joe Morris (NTM)

23:47

New subject: [SLE] What is so special on /dev/hda? was how to make device permissions stick?

Peter Sutter wrote:

...

resmgr seems to dislike ssh connections. So I may have to physically visit the system to test it out further. I tried this on a test system here, I get access to resmgr when logged in on a console or via kde, but not via ssh.

You need to adjust your pam config to get resmgr to work via ssh (/etc/pam.d/sshd). By default, it is not setup to work via ssh. In 9.3, it is a commented out line, easily changed. BTW, I think the only place to get some meaning from the result codes are to look in the source files for resmgr. -- Joe Morris Registered Linux user 231871

Carlos E. R.

20:09

New subject: [SLE] What is so special on /dev/hda? was how to make device permissions stick?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-01-18 at 10:04 +0800, Peter Sutter wrote:

...

To burn the dvd, growisofs needs physical access to the dvd burner, which is /dev/hda, and the permissions of /dev/hda change from 666 root:disks to 600 root:disks after a crash.

Did you read my email (Monday)? In file /etc/logindevperm: :0 0600 /dev/cdrom:/dev/cdrom1:/dev/cdrom2:/dev/cdrom3 ^^^^ It doesn't matter that it is /dev/hda the one that changes; /dev/cdrom is a symlink to it, so this service knows what it has to change. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFDzqCRtTMYHG2NR9URAhQqAJ9Ei6V0jf3JlyRht4oLPCm+QeKNWQCdE38z MixDv1c4pDPP3kKPZF3pjNY= =dl63 -----END PGP SIGNATURE-----

Peter Sutter

19 Jan 19 Jan

01:10

New subject: [SLE] What is so special on /dev/hda? was how to make device permissions stick?

On Thursday 19 January 2006 04:09, Carlos E. R. wrote:

...

The Wednesday 2006-01-18 at 10:04 +0800, Peter Sutter wrote:

...
To burn the dvd, growisofs needs physical access to the dvd burner, which is /dev/hda, and the permissions of /dev/hda change from 666 root:disks to 600 root:disks after a crash.

Did you read my email (Monday)?

In file /etc/logindevperm: :0 0600 /dev/cdrom:/dev/cdrom1:/dev/cdrom2:/dev/cdrom3

^^^^

It doesn't matter that it is /dev/hda the one that changes; /dev/cdrom is a symlink to it, so this service knows what it has to change.

-- Cheers, Carlos Robinson Thanks, Carlos.

No, I did not read your email from Monday, I did not get this one but I could find it on http://linux.derkeiler.com/Mailing-Lists/SuSE/2006-01/ I will give this a go. Thanks Peter

Roger Oberholtzer

22 Jan 22 Jan

10:43

New subject: [SLE] What is so special on /dev/hda? was how to make device permissions stick?

On Wed, 2006-01-18 at 21:09 +0100, Carlos E. R. wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Wednesday 2006-01-18 at 10:04 +0800, Peter Sutter wrote:

...
To burn the dvd, growisofs needs physical access to the dvd burner, which is /dev/hda, and the permissions of /dev/hda change from 666 root:disks to 600 root:disks after a crash.

Did you read my email (Monday)?

In file /etc/logindevperm:

:0 0600 /dev/cdrom:/dev/cdrom1:/dev/cdrom2:/dev/cdrom3

How does logindevperms relate to udev and HAL? I would guess that if a device is already present when you log in, logindevperms will replace any udev/HAL settings. If the device gets inserted while logged in, the udev/HAL settings are used and not logindevperms. Joy. Another piece of the puzzle. And, what happens if someone logs in after you while you are logged in? login runs as root, so there is nothing stopping it from claiming the device for the new login. Meaning that any changes made by the first person would be set to logindevperms when the second person logs in. I guess the first item on each logindevperms line allows a bit of control over this. But I would happy to fully understand the interaction with udev/HAL. The default logindevperms explains why you only get the device settings when you log in as the first GUI login on the console, as only that is defined in the default SUSE logindevperms. Anyway, thanks for the pointer to logindevperms. It is now on the radar. Too bad it still does not explain why /dev/ttyS0 is set to rw access only for the current login. I have not traced who does that. -- Roger Oberholtzer

Carlos E. R.

15:02

New subject: [SLE] What is so special on /dev/hda? was how to make device permissions stick?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-01-22 at 11:43 +0100, Roger Oberholtzer wrote:

...

...
In file /etc/logindevperm:

:0 0600 /dev/cdrom:/dev/cdrom1:/dev/cdrom2:/dev/cdrom3

How does logindevperms relate to udev and HAL?

It doesn't, or not directly. HAL: | 1.1. About | | This document concerns the specification of HAL which is a piece of | software that provides a view of the various hardware attached to a | system. In addition to this, HAL keeps detailed metadata for each piece of | hardware and provide hooks such that system- and desktop-level software | can react to changes in the hardware configuration in order to maintain | system policy. So, any piece of hardware is listed by it (try "lshal"). With udev I'm not familiar, but it serves to create the devices files (the /dev tree) on the fly. I suppose it gets info from hal (hardware abstraction layer?) about which node to create. What permissions does it use? Dunno. Looking at it, it is configured in /etc/udev/udev.conf. I see two interesting entries: udev_log - set to "yes" if you want logging, else "no" udev_log="yes" # udev_perms - The name and location of the permissions device udev_devperms="/dev/devperms" You should have a look at file "/dev/devperms" to see what it has, mine is empty. Udev is active in my 9.3, but the device nodes are static, I think (judging by the creation date). Not sure how to know. Grepping with "mc" in "/etc/udev/" for references to "cdrom" I don't find permissions references. Looking for "hda" I find two, but I don't think those are the ones we are looking for: KERNEL="dos_hda*", NAME="%k", GROUP="disk", MODE="660" KERNEL="i2o/hda*", NAME="%k", GROUP="disk", MODE="660" Finally, we have "logindevperm" (man logindevperm): | NAME | /etc/logindevperm - configuration file for pam_devperm.so So it is used by PAM.

...

I would guess that if a device is already present when you log in, logindevperms will replace any udev/HAL settings. If the device gets inserted while logged in, the udev/HAL settings are used and not logindevperms.

Not sure of that.

...

Joy. Another piece of the puzzle.

And, what happens if someone logs in after you while you are logged in? login runs as root, so there is nothing stopping it from claiming the device for the new login. Meaning that any changes made by the first person would be set to logindevperms when the second person logs in.

No, the permissions do not change, the first user keeps control.

...

I guess the first item on each logindevperms line allows a bit of control over this. But I would happy to fully understand the interaction with udev/HAL. The default logindevperms explains why you only get the device settings when you log in as the first GUI login on the console, as only that is defined in the default SUSE logindevperms.

It doesn't matter if you log in X or in the console, as long as it is a local one. Or it did not when I looked at this time ago, I might be mistaken.

...

Anyway, thanks for the pointer to logindevperms. It is now on the radar. Too bad it still does not explain why /dev/ttyS0 is set to rw access only for the current login. I have not traced who does that.

The /dev/ttyS0 is symlinked to /dev/modem: look for this one in those configuration files and you will find it. I will shove more clutter on your radar: have a look at /etc/resmgr.conf as well :-P Anyway, just try to modify the cdrom line in logindevperm, and find out if it solves your issue. Or, comment it out, and find if it sticks put. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD056NtTMYHG2NR9URAr7nAJ9BbklRET8RJoVWMlIjrdojg8gpdQCffo9Q Kl3MiD1VBwuZm/gvYe47GS4= =wRLZ -----END PGP SIGNATURE-----

Peter Sutter

23 Jan 23 Jan

01:14

New subject: [SLE] What is so special on /dev/hda? was how to make device permissions stick?

On Sunday 22 January 2006 18:43, Roger Oberholtzer wrote:

...

On Wed, 2006-01-18 at 21:09 +0100, Carlos E. R. wrote:

...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Wednesday 2006-01-18 at 10:04 +0800, Peter Sutter wrote:

...
To burn the dvd, growisofs needs physical access to the dvd burner, which is /dev/hda, and the permissions of /dev/hda change from 666 root:disks to 600 root:disks after a crash.

Did you read my email (Monday)?

In file /etc/logindevperm: :0 0600 /dev/cdrom:/dev/cdrom1:/dev/cdrom2:/dev/cdrom3

How does logindevperms relate to udev and HAL? I would guess that if a device is already present when you log in, logindevperms will replace any udev/HAL settings. If the device gets inserted while logged in, the udev/HAL settings are used and not logindevperms.

Joy. Another piece of the puzzle.

After reading all the man pages of resmgr, logindevperm etc. and setting the permissions at various places (/etc/permissions, /etc/logindevperm, /etc/resmgr.conf) I am still not getting the desired result. It works if the login is interactive on a console or to the graphical user interface (I have installed this in the meantime), but it seems not to work for apache web server or processes initiated via cronjobs. I still need to run SuSEconfig manually after a reboot/crash to gain write access to /dev/hda (via /etc/permissions) for these to work. snip... Peter

Carlos E. R.

24 Jan 24 Jan

00:30

New subject: [SLE] What is so special on /dev/hda? was how to make device permissions stick?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-01-23 at 09:14 +0800, Peter Sutter wrote:

...

After reading all the man pages of resmgr, logindevperm etc. and setting the permissions at various places (/etc/permissions, /etc/logindevperm, /etc/resmgr.conf) I am still not getting the desired result. It works if the login is interactive on a console or to the graphical user interface (I have installed this in the meantime), but it seems not to work for apache web server or processes initiated via cronjobs. I still need to run SuSEconfig manually after a reboot/crash to gain write access to /dev/hda (via /etc/permissions) for these to work.

Try removing or comenting out the cdrom line in /etc/logindevperm. Or make the device node, what was it, unmuttable? - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD1XUNtTMYHG2NR9URAgE/AJ47/8nn9WE7G0jme+hWbma+pYkiXACfa++7 VkGLX9EWBrU3RTsKsG+4sRQ= =mHxm -----END PGP SIGNATURE-----

Silviu Marin-Caea

17 Jan 17 Jan

10:52

New subject: [SLE] How to make device permissions stick?

On Monday 16 January 2006 12:28, Peter Sutter wrote:

...

After the system is re-booted, the device permissions are back to brw------- 1 root disk 3, 0 Oct 2 2004 /dev/hda

The permissions for the device are managed by resmgr rpm -qi resmgr rpm -ql resmgr

6671

Age (days ago)

6679

Last active (days ago)

List overview

Download

20 comments

8 participants

participants (8)

Carlos E. R.
Joe Morris (NTM)
Patrick Shanahan
Peter Sutter
Randall R Schulz
Roger Oberholtzer
Silviu Marin-Caea
Sunny