root can't delete Files on NSS?
Thomas Reiß
stupid Question.
Can't user "root" remove any Files from other eDirectory User on NSS
Volumes?
Thomas
Thomas Reiß
> Thomas Rei�;1925798 Wrote:
>> �hmm.....
> (http://www.novell.com/documentation/oes2/stor_nss_lx_nw/?page=/documentation/oes2/stor_nss_lx_nw/data/access.html)
> which explains in more detail. Ultimately root has the same role as
> SYSTEM had on NetWare - with the exception that -you actually need to
> login- to be root. :)
>
> -- Bob
>
Thank You for the Link!
Hmm, then i must do something wrong.
Let me explain.
- I put a File via Novell Client to a NSS Volume as a LUM Enabled User
(Maybe User "Thomas")
- I login (ssh) as user "root" to OES2 Server
- I can see the stored file from User "Thomas"
- I can not remove this file as User "root" ?
Can you do that?
Thomas
Thomas Reiß
> reiss;1926485 Wrote:
>> Update
>>
>> I
>> ... completed OK [elapsed time = 6 Seconds 18446744073708930 msecs 706
>> usecs]
>>
>> That's really BAD!
>>
>> Hmm, i put the latest big Updates onto the Server an reboot it....
>
> Wow 18446744073708930 _milliseconds_ is a very long time, specifically
> 584542 _years_. ( I left out the 6 seconds and 706 microseconds. )
>
> Well, hope springs eternal that patches will fix any problem. Please
> tell us either way.
>
> Assuming you still have this issue after. Check for errors for namcd.
> Issue a *namconfig cache_refresh* and watch /var/log/messages, perhaps
> something interesting will show up.
>
> Assuming that NCP clients are acquiring rights correctly, then the
> issue is most likely not an issue with rights on the NSS volumes, but
> rather with the LUM side of things which maps local linux users to edir
> users.
>
> Not sure how that causes root to have issues, as NSS should understand
> root is root. I tried breaking this in a few ways on a OES2SP1 test
> box, and could not break root access. ( Messing up the LUM config or
> breaking eDir or whatever would interfere with local LUM enabled users
> from accessing NSS on that server, but I could never get root to be
> broken. -And I'm pretty good at breaking things. -
>
> So hopefully its a bug / oddity that will be resolved when you patch.
>
>
> -- Bob
>
>
Just for Info.
I installed latest Patches and reboot the Machine.
Root could not remove the file again.
But i found the File have the "Read Only" Flag!
After i uncheck these Flag with help of Novell Client, root can delete
this File!?
Is this work as design?
This would be bad, because i can't run cron Scripts on these Directory's
when root didn't have full access...
Regards
Thomas
Thomas Reiß
[...]
> You can modify NSS attributes from the cli / scripts using the 'attrib'
> (http://www.novell.com/documentation/oes2/stor_nss_lx_nw/?page=/documentation/oes2/stor_nss_lx_nw/data/attrib.html)
> command. It also support recursive operations, and can be executed
> from find -exec ...
[...]
Thanks to all!
Very usefull Infos.
Thomas
Thorsten Kampe
>
> Thomas Reiß;1928907 Wrote:
> > Root could not remove the file again.
> >
> > But i found the File have the "Read Only" Flag!
> > After i uncheck these Flag with help of Novell Client, root can delete
> > this File!?
> >
> > Is this work as design?
> >
> delete inhibit flag is set on the NSS volume.
>
> As I've understood the reason for this is that NSS is a ported
> filesystem and not a native Linux/POSIX filesystem.
Native Linux file systems (that have attributes) behave the same way.
For instance ext3 and "append only".
Thorsten
Thorsten Kampe
> Thorsten Kampe;1930053 Wrote:
> > * magic31 (Fri, 05 Feb 2010 21:56:04 GMT)
> account with force delete options?
Actually I meant "immutable" and not "append only" (which should behave
similarly):
root@sles11:~/tmp # touch immutable.txt
root@sles11:~/tmp # chattr +i immutable.txt
root@sles11:~/tmp # rm -f immutable.txt
rm: cannot remove `immutable.txt': Operation not permitted
root@sles11:~/tmp # chattr -i immutable.txt
root@sles11:~/tmp # rm -f immutable.txt
root@sles11:~/tmp #
Thorsten