Find the answer to your Linux question:
Page 4 of 5 FirstFirst 1 2 3 4 5 LastLast
Results 31 to 40 of 45
Originally Posted by Lakshmipathi Go through the above replies from Rubberman and me discussing about vi and cat. You will get better understanding of it Thank you! now i know ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #31
    Just Joined! bitzsk's Avatar
    Join Date
    Apr 2009
    Location
    Far, Far, Away on the earth
    Posts
    25

    Quote Originally Posted by Lakshmipathi View Post
    Go through the above replies from Rubberman and me discussing about vi and cat. You will get better understanding of it
    Thank you! now i know more about this.

  2. #32
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,558
    If you were running SElinux, access control lists should protect from unauthorized updates of files, including by root. Unfortunately, I am not particularly experienced in that domain, so I cannot say categorically that you could provide such protections, though my studies tell me that it should be so.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #33
    Just Joined! bitzsk's Avatar
    Join Date
    Apr 2009
    Location
    Far, Far, Away on the earth
    Posts
    25
    Thank you!

    actually, i use xen virual machine to do this. there are two domains named dom0 and domU. dom0 can manage domu.whenever domU wants to visit harddisk, it need to send the sectors/blocks which it read/writes to dom0.and dom0 send the request to the low-level real hardware drivers to do the operation.

    when i read or write a file in DomU, front end driver will send the block number to back-end driver Dom0 , and then in dom0 i can check if the block could be write or not. next dom0 send the block number to the real device driver for read/write.

    i just trust dom0 , but not trust domU. i want to save the blocks of improtant files of domU into dom0, when write operation happend in domU, domU will send the request struct , which contain the sectors need to write, to dom0, next, in dom0 compare the sector number. if the sector numbers is which i want to protect, the write operation will be stoped by dom0. even if intruder get the root privilege in domU, he can't change the file (for example :files in /bin dir) which i protected.

  4. #34
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,558
    Thanks for the clarification. I will think about this and get back to you tomorrow. Time for bed (it is 12:30am here now).
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  5. #35
    Just Joined! bitzsk's Avatar
    Join Date
    Apr 2009
    Location
    Far, Far, Away on the earth
    Posts
    25
    OK. I wish you a good sleep

  6. #36
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,558
    So, basically, you need to do 1 of 2 things:

    1. Write your own kernel module that intercepts calls to the hard drive and decides whether to pass it thru to the original driver, or to issue a SIGPERM to the calling process because it is trying to write.

    2. Modify the client OS's driver to do the same.

    Which approach is best for you is something I cannot say. With either approach, you need to have some means of telling the driver which sector ranges of sectors on which devices are protected. I think that most of the code will be the same in either case, though I would personally faver #1 since I woudn't have to deal with actual kernel mods and applying the changes to any kernel disc driver updates of the client OS.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  7. #37
    Just Joined! bitzsk's Avatar
    Join Date
    Apr 2009
    Location
    Far, Far, Away on the earth
    Posts
    25
    Thank you,

    i also think the first approach is better!

    while the block number could changed by the modify of a file. could i use inode number to identify a file? because both vi and cat /echo don't change the inode number of the file.

    but can i get the inode number info in the device driver layer? while it seems only send which sectors/blocks i need to read or write, i not see anything about the inode info in the request struct as follow:

    Code:
    /*
     * try to put the fields that are referenced together in the same cacheline
     */
    struct request {
    	struct list_head queuelist;
    	struct list_head donelist;
    
    	unsigned long flags;		/* see REQ_ bits below */
    
    	/* Maintain bio traversal state for part by part I/O submission.
    	 * hard_* are block layer internals, no driver should touch them!
    	 */
    
    	sector_t sector;		/* next sector to submit */
    	unsigned long nr_sectors;	/* no. of sectors left to submit */
    	/* no. of sectors left to submit in the current segment */
    	unsigned int current_nr_sectors;
    
    	sector_t hard_sector;		/* next sector to complete */
    	unsigned long hard_nr_sectors;	/* no. of sectors left to complete */
    	/* no. of sectors left to complete in the current segment */
    	unsigned int hard_cur_sectors;
    
    	struct bio *bio;
    	struct bio *biotail;
    
    	void *elevator_private;
    	void *completion_data;
    
    	int rq_status;	/* should split this into a few status bits */
    	int errors;
    	struct gendisk *rq_disk;
    	unsigned long start_time;
    
    	/* Number of scatter-gather DMA addr+len pairs after
    	 * physical address coalescing is performed.
    	 */
    	unsigned short nr_phys_segments;
    
    	/* Number of scatter-gather addr+len pairs after
    	 * physical and DMA remapping hardware coalescing is performed.
    	 * This is the number of scatter-gather entries the driver
    	 * will actually have to deal with after DMA mapping is done.
    	 */
    	unsigned short nr_hw_segments;
    
    	unsigned short ioprio;
    
    	int tag;
    
    	int ref_count;
    	request_queue_t *q;
    	struct request_list *rl;
    
    	struct completion *waiting;
    	void *special;
    	char *buffer;
    
    	/*
    	 * when request is used as a packet command carrier
    	 */
    	unsigned int cmd_len;
    	unsigned char cmd[BLK_MAX_CDB];
    
    	unsigned int data_len;
    	unsigned int sense_len;
    	void *data;
    	void *sense;
    
    	unsigned int timeout;
    	int retries;
    
    	/*
    	 * completion callback. end_io_data should be folded in with waiting
    	 */
    	rq_end_io_fn *end_io;
    	void *end_io_data;
    };

  8. #38
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,558
    I'm not familiar enough with the disc driver internals to say, but I suspect that since this is dealing with raw sectors, the inodes are not relevant, and in fact their sectors may well be part of the request.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  9. #39
    Just Joined! bitzsk's Avatar
    Join Date
    Apr 2009
    Location
    Far, Far, Away on the earth
    Posts
    25
    Thanks a lot!

    by the way , may i ask you a non-tech question. how to show the signature pics in this forum? i have update the pic but not see it in my topic thread.

  10. #40
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,558
    Quote Originally Posted by bitzsk View Post
    Thanks a lot!

    by the way , may i ask you a non-tech question. how to show the signature pics in this forum? i have update the pic but not see it in my topic thread.
    The picture that appears to the left of a posting is your avatar, not your signature picture. Your profile picture is another image and appears in your bio pages. I don't have a profile picture, but I do have an avatar (Gumby - aka Rubberman).
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

Page 4 of 5 FirstFirst 1 2 3 4 5 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •