Look but not touch.....!

[tarn]

Anyone suggest an option for setting up a/(some) users that have the ability to traverse the whole server and look but not change anything (kind of read only).

I needs to be as non-intrusive as posible in adding this access as it is a controled reference model.

Soalris 2.6

Will sudo allow me to grant ALL but with ro ?

Thanks in advance.
Laurie.

 

[jad]

how do you mean 'traverse'

do you mean ... you want some users to be able to view files like /etc/shadow but without the ability to change it?

i guess you could possibly have a copy of 'cat' that is suid'd as root ...

if you sudo 'more' it might well allow you to 'v' to edit the file as root.
if you sudo cat, it might allow the whole command to be sudo'd i.e. 'cat /dev/null > /etc/shadow' would quickly cripple the system.

but an suid cat equivalent command with group execute (not world), and the users you want to be able to see a file could be in the groups file as group members, would allow them to access the files.

looking at directory structures would be hard as well.
i guess you could do the same with 'ls'

hmm.

another alternative is to give an automount point that is a read-only mount point, but controlling access is harder.

 

[tarn]

Thanks for yuor thoughts jad, yes the developers require access to move freely around the servers and read (any number of) files but do not require (or want) the ability to change anything ..... thats our job :¬).

Yes sudo would be tricky as there is nothing to stop them doing > /etc/shadow !!

Our standard users can move quite freely around the servers so it may be a case of just blocking them from the server that is the master mount server for the filer.

Will NIS+ allow us to setup a user that is restricted to a specific (restricted) range of servers? anyone?

Laurie.

 

[SamBones]

Is the system they're needing to look at a live running system, or can it be a snapshot? If it's just a reference model and the whole thing is under 4.7 Gig, you could burn it to a DVD-ROM with the permissions set so anyone can read every file. That way you could either mount it at a mount point just for reference, or even pass it around so people can even peruse it on their PC.

Hope this helps.

 

[tarn]

That’s a nice idea SamBones but this is a little larger scale than that "try thinking major ISP" and you can imagine that 4.7Gig is probably not even a swap partition on one of the 30 or so reference model servers, but like I said it's a nice idea for a smaller project.

I believe we have the answer, as the system is "read only" unless securely accessed from the master filer mount server (even as root), so then we just give them a standard account and block their access to the master! We can give them sudo to read where a standard user can't access and they still wont be able to change anything anyway :¬)

Thanks everyone for your input, it just goes to prove "Its good to talk" !

Laurie.

 

[jad]

are you using a diskless client?
if not sudo could still possibly be used to access the non read-only part of the file system ...

 

[mrn]

Can't the "Major ISP" buy a test system? No stop I used to work for a top 5 ISP (UK) I know the answer..... ;o)

Why not create a user and use alias on harmful commands, I appricate this would take an age or create your own shell with only a few commands available I know some systems have a restricted shell available like rksh.

If you were using SAN storage you could look at split mirror.

--
| Mike Nixon
| Unix Admin
|
----------------------------

 

[DblBass]

What we do is export the partition as "ro" then mount it to a common mount point using automount.

example:

the data is in /export/volume1/data
the /etc/dfs/dfstab has export/volume1/data shared as "ro"
auto_direct has server:/export/volume1/data mount to /data

you can control which users and which workstations get to mount the data in the auto_direct or in the dfstab entries.

or
Or, with Solaris 8 and use rbac accounting to control the users access

Joe

 

[tarn]

Thanks again guys, once again you’ve offered some nice suggestions.

I believe that with our simple solution of blocking access to the "only" server that has write access to the filers, is probably the easiest way to allow the developers to look around the reference platform. Only requiring a minor change to that "one" admin server will have little impact on a controlled configuration environment.


Cheers,
Laurie